| maco | i just attempted to allocate the permissions with edit_acl.py. i got an error. can the DMB seriously not do that? | 00:06 |
|---|---|---|
| stgraber | maco: only TB can | 00:06 |
| maco | that's annoying | 00:07 |
| jcrigby | maco, thanks for trying | 00:11 |
| micahg | that's why I said what I said :) | 00:12 |
| micahg | any DMB member can e-mail the TB, but in the past it's been the person chairing | 00:13 |
| jcrigby | micahg, I sent an email to persia | 00:14 |
| jcrigby | per your advice | 00:14 |
| micahg | jcrigby: k, if you need this immediately, you could ask one of the other DMB members to do it | 00:16 |
| jcrigby | micahg, it can wait until tomorrow. If I don't hear back from persia I will do that | 00:17 |
| broder | email to persia> i thought persia didn't read e-mail | 00:19 |
| micahg | jcrigby: I would offer to sponsor but E_NOTACOREDEV | 00:20 |
| jcrigby | broder, ok I won't be surprised if I don't here back from him then:) | 00:20 |
| jcrigby | micahg, no problem | 00:20 |
| stgraber | jcrigby: do you have that package around somewhere? as you're supposed to have upload rights, I'm fine uploading it for you. | 00:24 |
| === tkamppeter_ is now known as tkamppeter | ||
| jcrigby | stgraber, actually one of the reasons for uploading today was to test the uploading:) | 00:25 |
| jcrigby | stgraber, I actually have 5 linaro kernels to upload total | 00:26 |
| stgraber | jcrigby: ok. Got to go now anyway. If it's not solved tomorrow and you want it uploaded, just poke me and I'll upload all of them. | 00:28 |
| jcrigby | stgraber, thanks! | 00:28 |
| apw | help /buffer | 00:39 |
| === ion_ is now known as ion | ||
| micahg | RoAkSoAx: why would you add an epoch to a new package? | 01:18 |
| RoAkSoAx | micahg cause it ships a binary that is another spurce package which also has and epoc and to upgrade is neecessary | 01:19 |
| RoAkSoAx | is in another source package aswell | 01:19 |
| micahg | RoAkSoAx: you can do that in debian/rules with a substitution, non need to bump the source like that | 01:20 |
| RoAkSoAx | micagh the shource is was already bumped in snother in the old.ackage and needed to be in new package | 01:21 |
| micahg | RoAkSoAx: huh? you can bump a binary separately from the source, see thunderbird in oneiric for an example | 01:22 |
| RoAkSoAx | k | 01:22 |
| micahg | I would suggest having this deleted and roll back the epoch, it'll make syncing with Debian harder | 01:22 |
| RoAkSoAx | bthats how it was handled.by debian initially | 01:23 |
| RoAkSoAx | y | 01:23 |
| micahg | RoAkSoAx: is Debian introducing the same epoch? | 01:23 |
| RoAkSoAx | cluster-agents was handled by thst when got seplarated from heartbeat | 01:23 |
| RoAkSoAx | yes we will have same lackage | 01:24 |
| micahg | RoAkSoAx: I mean in the new package, if you're sure they'll take the same epoch, that's fine then | 01:24 |
| RoAkSoAx | yes they will | 01:24 |
| micahg | k | 01:24 |
| RoAkSoAx | they are waiting for me to.forward it | 01:24 |
| RoAkSoAx | thats all.already been discussed at AUDS | 01:25 |
| === asac_ is now known as asac | ||
| alex__ | Anyone know when the Ubuntu key servers will be back online? | 04:36 |
| pitti | Good morning | 05:46 |
| micahg | hi pitti :) | 05:47 |
| micahg | great timing :) | 05:47 |
| pitti | hey micahg -- ready to release the lot? :-) | 05:47 |
| micahg | pitti: can I get you to promote all the firefox locale binaries in -updates and -security :) | 05:47 |
| micahg | pitti: I had jdstrand do that earlier, we seemed to have forgotten to promote the locale packages to main though | 05:48 |
| pitti | ok, I see that firefox itself is in natty-updates/main | 05:48 |
| pitti | doing | 05:49 |
| micahg | thans | 05:49 |
| micahg | *thanks | 05:49 |
| pitti | seems the langpacks made it alright | 05:51 |
| micahg | \o/ | 05:51 |
| pitti | so let's hope not too many people only have main enabled, and thus broken the upgrade | 05:51 |
| pitti | micahg: promoted now; will hit the mirrors in 70 mins | 05:51 |
| micahg | I've only had one bug report so far and I think that was due to the langpacks hitting after firefox (we'll watch for that next time) | 05:52 |
| micahg | pitti: thanks | 05:52 |
| pitti | slangasek: hey Steve | 06:46 |
| slangasek | pitti: hey, how goes? | 06:47 |
| pitti | pretty well, thanks! | 06:47 |
| pitti | slangasek: I was pondering debian bug 583958, and the 'usergroups' option of pam_umask | 06:47 |
| ubottu | Debian bug 583958 in libpam-modules "enable pam_umask usergroups by default" [Normal,Open] http://bugs.debian.org/583958 | 06:47 |
| * slangasek nods | 06:48 | |
| pitti | slangasek: your/ceg's proposal seems to be to change pam_umask to read the USERGROUPS_ENAB option, but I wonder how that should behave wrt. the "usergroups" option | 06:48 |
| pitti | slangasek: if we make this an "and" , i. e. when you specify "usergroups" it reads login.defs, then we might break systems which expect usergroups to be enabled that way (but disabled it in login.defs) | 06:49 |
| pitti | although this admittedly would be a weird configuration | 06:49 |
| slangasek | pitti: ah, I was thinking 'or' | 06:49 |
| pitti | so the other optiohn would be to imply "usergroups" if login.defs says USERGROUPS_ENAB | 06:49 |
| slangasek | and then effectively deprecating the 'usergroups' module option | 06:49 |
| pitti | right, that was my idea; so you agree? | 06:50 |
| slangasek | yep! | 06:50 |
| pitti | so the plan would be: | 06:50 |
| pitti | - read login.defs USERGROUPS | 06:50 |
| pitti | - document "usergroups" as deprecated | 06:50 |
| pitti | - add pam_umask without any options to common-session{,-noninteractive}, as per http://launchpadlibrarian.net/42107572/pam_umask-for-common-sessions.patch | 06:50 |
| pitti | sounds ok? | 06:51 |
| slangasek | yep, sounds good to me | 06:51 |
| pitti | thanks | 06:51 |
| slangasek | thank *you* :) | 06:52 |
| pitti | I updated the WIs accordingly | 06:53 |
| === freeflyi1g is now known as freeflying | ||
| slangasek | pitti: looking closely I see that there's an explicit 'UMASK' setting in our login.defs, which ought to take precedence if set; so we should update login to comment that out at the same time | 07:08 |
| pitti | slangasek: that's Debian bug 583971 | 07:08 |
| ubottu | Debian bug 583971 in login "login.defs: UMASK 022 (and have pam_umask relax it to 002 for private usergroups)" [Normal,Open] http://bugs.debian.org/583971 | 07:08 |
| pitti | slangasek: I added a WI to update the documentation there | 07:08 |
| pitti | slangasek: so you'd rather prefer an implicit default of 022, and not have USERGROUPS_ENAB relax that to 002 automatically? | 07:09 |
| slangasek | I don't think USERGROUPS_ENAB should override an explicit UMASK | 07:09 |
| slangasek | or was that how login worked before PAM? | 07:09 |
| pitti | we haven't used usergroup magic by default in Debian/Ubuntu, so this is a yet undefined territory | 07:10 |
| pitti | in the past, /etc/profile just had a static "umask 022", I think | 07:10 |
| pitti | lucid still has | 07:11 |
| slangasek | "before PAM" was a long time ago :) | 07:11 |
| pitti | ah, I took that to mean "before pam_umask" | 07:11 |
| slangasek | we don't have to be bound by pre-PAM behavior, but the meaning of login.defs is defined by login, not by pam | 07:11 |
| slangasek | so it would be best to be consistent | 07:11 |
| pitti | ok, so comment it out by default, and have implicit default be "022 with automatic usergroups" | 07:14 |
| pitti | ? | 07:14 |
| pitti | and if it's defined anywhere (login.defs, /etc/default/login, and all the other places that pam_umask looks for), just take it as it is | 07:15 |
| didrocks | good morning | 07:21 |
| pitti | slangasek: the email thread and bug report seem to think that the historic behaviour is that USERGROUPS_ENAB did modify the UMASK default | 07:23 |
| pitti | slangasek: it would have the added benefit that you could set 077 and automatically get 007 for user groups | 07:25 |
| pitti | but it's a bit less expected indeed | 07:25 |
| pitti | slangasek: I'll follow up to the Debian bugs to digest it there | 07:26 |
| === hunger_ is now known as hunger | ||
| wgrant | pitti: >= Natty, not >= Oneiric? | 07:56 |
| pitti | wgrant: hmm, good question; I guess we could start with oneiric only | 07:57 |
| pitti | wgrant: updated bug description | 07:58 |
| wgrant | pitti: OK. >= Natty is easier, but >= Oneiric is probably safer. | 07:59 |
| dholbach | good morning | 08:05 |
| === smb` is now known as smb | ||
| seb128 | do we have a wiki page or something explaining how to use submittodebian without a mta configured? | 08:34 |
| seb128 | i.e without having a working sendmail or whatever | 08:34 |
| didrocks | I think there isn't last time I check | 08:35 |
| seb128 | got a contributor who tried to send a patch to debian following the wiki and says he's blocked because summittodebian write the email but doesn't manage to send it | 08:35 |
| seb128 | dholbach, ^ | 08:35 |
| seb128 | he's asking if he can tell submittodebian to use his gmail account or something | 08:36 |
| micahg | seb128: https://wiki.ubuntu.com/Debian/Bugs#Using_reportbug_to_report_bugs_in_Debian | 08:36 |
| micahg | that's the closest I know of | 08:36 |
| micahg | and yes, it's not explicit | 08:36 |
| seb128 | micahg, it doesn't tell you "that relies on you to be a sysadmin and having configured your command line to send emails" | 08:37 |
| apw | load /usr/share/weechat/python/go.py | 08:37 |
| micahg | seb128: no, if you run reportbug --configure, it should walk you through it | 08:38 |
| didrocks | also, IIRC, submittodebian is reporting with the ubuntu version which breaks the version tracking there is in debian (got flamed once because of that, now I edit it or report manually) | 08:38 |
| micahg | but idr, it's been almost 2 years | 08:38 |
| seb128 | micahg, but users don't want to configure a mail server, they just want to send the email on gmail or whatever | 08:38 |
| seb128 | re | 08:41 |
| seb128 | sorry, got some issues | 08:41 |
| micahg | seb128: not configure a mail server, configure reportbug | 08:41 |
| micahg | there's an smtphost setting | 08:41 |
| seb128 | ok | 08:42 |
| seb128 | well I still think we could do better ;-) | 08:42 |
| micahg | indeed :) | 08:42 |
| seb128 | like at least give an option "send it using your normal email client" | 08:42 |
| seb128 | which would just do what i.e nautilus-sendo is doing | 08:42 |
| seb128 | calling the composer and attach the patch and set the title and text or something | 08:42 |
| micahg | well, I just use Debian's SMTP host actually, it's a lot easier that opening in the mail client (and Debian sends you a copy in any event) | 08:43 |
| seb128 | it's a free to world smtp? | 08:43 |
| micahg | yep | 08:43 |
| seb128 | like you can send a patch with your gmail account by it? | 08:43 |
| micahg | well, at least to report bugs :) | 08:43 |
| seb128 | ok | 08:43 |
| micahg | sure, you set the address in the reportbugrc file | 08:44 |
| seb128 | thanks, I will reply that to the user | 08:44 |
| dholbach | is there something that we can improve in the docs? | 08:45 |
| micahg | dholbach: invite people to set up reportbug before using submitodebian? | 08:46 |
| dholbach | yes | 08:46 |
| dholbach | seb128, micahg: I followed up on https://bugs.launchpad.net/ubuntu-packaging-guide/+bug/704845 | 08:48 |
| ubottu | Ubuntu bug 704845 in Ubuntu Packaging Guide "Add article explaining how to work with Debian/Upstream" [Undecided,In progress] | 08:48 |
| dholbach | didrocks, is that a bug that can be fixed in submittodebian? | 08:48 |
| didrocks | dholbach: I guess that we should have a way to replace with the current version (or the closest we have) in debian | 08:49 |
| seb128 | dholbach, thanks, I think ideally submittodebian would ask you whether you want to send it from a command line and telling you what is configured or not or give you the option to open the dump in your email client | 08:51 |
| dholbach | yes, that'd be nie | 08:52 |
| dholbach | nice | 08:52 |
| seb128 | so people who want to use their normal email client and see what they send can do that rather than relying on some command line magic to send the email where they get no feedback on whether it worked | 08:52 |
| dholbach | can somebody file a bug on ubuntu-dev-tools about that? | 08:52 |
| micahg | seb128: reportbug tells you that you should receive a response w/in an hour I think | 08:52 |
| seb128 | it's still not really intuitive | 08:52 |
| seb128 | what the contributor emailed me is | 08:53 |
| seb128 | "The only problem was that I tried using submittodebian (for the first time) but I still haven't found out how to get it send the emails. I reported a bug on this since the tool outputs that the patch was sent but in /var/log/mail.log I could see that this was not the case." | 08:53 |
| micahg | seb128: right, it needs more sanity checks for either a local MTA or a remote one | 08:54 |
| seb128 | "Do you know how to configure sendtodebian, reportbug or postfix to actually send mails using gmail for example(or whatever the easyest way is)?" | 08:54 |
| * micahg also thought reportbug offered to configure the first time it's run, does submittodebian bypass that? | 08:55 | |
| seb128 | dholbach, ok, I will do a bit of checking on what works and not and maybe check open bugs and send an email to ubuntu-devel about that | 08:57 |
| seb128 | dholbach, then I can open a bug as well about what comes out from it | 08:58 |
| pitti | slangasek: OK, that's working nicely now; I sent https://code.launchpad.net/~pitti/pam/pam-umask/+merge/65451 your way for a first review | 08:59 |
| * dholbach hugs seb128 | 09:00 | |
| * seb128 hugs dholbach | 09:02 | |
| tumbleweed | seb128: is this in reference to bug 800429? | 09:06 |
| ubottu | Launchpad bug 800429 in ubuntu-dev-tools (Ubuntu) "submittodebian needs configured mail agent" [Undecided,New] https://launchpad.net/bugs/800429 | 09:06 |
| seb128 | tumbleweed, yes | 09:06 |
| seb128 | dholbach, ^ the bug about the issue (the contributor who emailed me opened it) | 09:07 |
| tumbleweed | I think it's relatively straightforward to display some instructions if a ~./reportbugrc doesn't exist | 09:07 |
| seb128 | why do a reportbugrc need to exist? | 09:08 |
| seb128 | that seems backward, it should just do it works and call your email client composer | 09:08 |
| seb128 | with the patch attached and the title and text set | 09:08 |
| tumbleweed | using an unconfigured reportbug is very irritating (it won't let you set severities, for a start) | 09:08 |
| tumbleweed | and unless the user has an MTA on their machine, tehy'll want to configure it to use another MTA | 09:09 |
| seb128 | why does it need to use reportbug to start? | 09:09 |
| tumbleweed | because that's the official method for reporting bugs to debian? | 09:09 |
| tumbleweed | how much do we want users to learn how to interact with debian's BTS (which does require some learning)? | 09:10 |
| micahg | reportbug is used to find if there's an existing bug in the BTS to attach the patch to as well as manipulate that bug | 09:10 |
| tumbleweed | err new developers | 09:10 |
| tumbleweed | it doesn't attach the patch for me, (when using it with mutt), must actually look into that... | 09:11 |
| seb128 | tumbleweed, learning the Debian BTS is fine, learning how to configure sendmail to send a bug is not | 09:11 |
| tumbleweed | seb128: you don't need to. reportbug can use your ISPs MTA, gmails, or even debian's | 09:11 |
| seb128 | well somewhat it manages to confuse contributors, cf the bug we are discussing | 09:12 |
| seb128 | I've to admit I usually copy the reportbug summary in my email client composer | 09:12 |
| seb128 | because submittodebian never worked for me either and I didn't want to bother fighting with mail servers when I've a working email client | 09:13 |
| seb128 | so it's not only that guy ;-) | 09:13 |
| tumbleweed | it's really not hard ot get reportbug to work. You just need to know that you need to configure it :) | 09:13 |
| seb128 | well that's what is driving contributors away | 09:13 |
| tumbleweed | indeed, and debian is aware of this, but there is lots of inertia (and some people are afraid that if it's too easy, they'll get bad bug reports) | 09:14 |
| seb128 | we are not talking about bug reports there, we are talking about patches | 09:15 |
| seb128 | which are sent in form of bug report, but those sort of bugs should be easy to open | 09:15 |
| seb128 | if the contributor is technical enough to send you a fix you probably want to make it easy for the fix to reach you | 09:16 |
| seb128 | it's not like saying you make easy to file "doesn't work" bugs | 09:16 |
| tumbleweed | we could easily make submittodebian drop in a .reportbugrc using Debian's MTA for bugs (and tell the user that it did so) | 09:16 |
| seb128 | ok, so please do that ;-) | 09:16 |
| seb128 | that would seem a good start | 09:17 |
| seb128 | though ideally I still think it should open whatever it did in the user preferred email client | 09:17 |
| seb128 | that way you can pick what email you want to use to send it, you have feedback it's sent, you have it archived in your outbox, etc | 09:17 |
| tumbleweed | is there a standard interface for giving an e-mail client a prepared email? | 09:18 |
| pitti | persia: in https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-qin-ubuntu-china we discussed "install sunpinyan by default, drop bopomofo" | 09:18 |
| pitti | persia: bopomofo maps to ibus-table-zhuyin as far as I can see, but we don't install that by default anywhere, nor does language-selector; am I missing something? | 09:18 |
| seb128 | tumbleweed, xdg-email is somewhat aiming at that I guess | 09:19 |
| seb128 | xdg-email [--utf8] [--cc address] [--bcc address] [--subject text] [--body text | 09:19 |
| seb128 | ] [--attach file] [ mailto-uri | address(es) ] | 09:19 |
| tumbleweed | that seems usable | 09:22 |
| pitti | echo body | mail -s "subject" address1 .. | 09:23 |
| pitti | but requires mailx, which we don't install by default | 09:23 |
| * tumbleweed is glad to see zack is still poking debian bug 590214 | 09:23 | |
| ubottu | Debian bug 590214 in reportbug "support for submitting bug reports via http" [Normal,Open] http://bugs.debian.org/590214 | 09:23 |
| pitti | so I guess xdg-email it is | 09:23 |
| Laney | and a configured MTA, which is the problem | 09:23 |
| pitti | ah, right | 09:24 |
| pitti | how can you not have one :) | 09:24 |
| seb128 | pitti, the discussion started because relying on a working system email setup is an issue, contributors don't want to have to deal with that | 09:25 |
| pitti | right, sorry, misunderstood | 09:25 |
| seb128 | you also get no feedback of what you send, not outbox archiving, etc | 09:25 |
| seb128 | pitti, no worry ;-) | 09:25 |
| tumbleweed | by default it CCs it to you, so you do get what you sent | 09:25 |
| seb128 | if it works | 09:25 |
| seb128 | if it doesn't you have no clue of what is happening and why | 09:25 |
| tumbleweed | however we can't get that if we use the debian public MTA | 09:25 |
| Laney | ? | 09:26 |
| micahg | pitti: can I get you to copy one more thing for me? | 09:26 |
| seb128 | out of knowing what system logs to read to figure what went wrong | 09:26 |
| pitti | micahg: sure | 09:26 |
| Laney | I've used X-Debbugs-CC with reportbug.d.o for ages | 09:26 |
| seb128 | Laney, X-Debbugs-CC? | 09:26 |
| micahg | pitti: firefox source, lucid from ubuntu-mozilla-security PPA | 09:26 |
| tumbleweed | Laney: I mean submission-time CC | 09:26 |
| Laney | does it matter? | 09:26 |
| tumbleweed | seb128: that CCs the bug after it's been filed, i.e. to other people who should know about it | 09:26 |
| pitti | micahg: to lucid-proposed? | 09:26 |
| tumbleweed | Laney: no, I don't think so (assuming it all works) | 09:27 |
| micahg | pitti: no, lucid-security | 09:27 |
| Laney | what env var does xdg-mail use? | 09:27 |
| Laney | http://paste.debian.net/120616/ :'( | 09:28 |
| pitti | micahg: done | 09:28 |
| micahg | pitti: thanks | 09:30 |
| dholbach | hey ev - I just noticed, there's ~ev and ~evand - do you think they can be merged somehow? | 10:27 |
| ev | dholbach: oh weird | 10:41 |
| ev | annoyingly I can't merge them as evand@ubuntu.com will bounce. I'll follow up with #launchpad | 10:41 |
| ev | thanks for bringing that to my attention | 10:41 |
| seb128 | tumbleweed, do you plan to send your clasp build fix to debian? | 11:47 |
| debfx | pitti, chrisccoulson: the new langauge packs pull in firefox (on natty and oneiric) | 11:49 |
| tumbleweed | seb128: did so (that was actually for testing submittodebian changes) | 11:50 |
| debfx | firefox-locale-* probably shouldn't depend on firefox | 11:50 |
| seb128 | tumbleweed, ok, it's not showing on http://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=clasp so I was wondering | 11:50 |
| tumbleweed | seb128: debian bug 631270 | 11:51 |
| ubottu | Debian bug 631270 in clasp "clasp: FTBFS with ld --as-needed" [Minor,Open] http://bugs.debian.org/631270 | 11:51 |
| seb128 | tumbleweed, thanks | 11:51 |
| * tumbleweed normally includes debian bug numbers in the patch before uploading to ubuntu (naughty me) :P | 11:52 | |
| seb128 | tumbleweed, sorry for picking on this one, I noticed a stack of build fixes in the sponsoring queue yesterday and none sent to debian, I'm trying to see how we do in regard of sending those to debian when we upload ;-) | 11:52 |
| seb128 | tumbleweed, ideally I think we should have the debian but reference in the patch or changelog | 11:52 |
| tumbleweed | yes, I usualyl do that | 11:52 |
| seb128 | it's a good practice and ensure the fix is sent back ;-) | 11:52 |
| diwic | does anybody know why my build fails on amd64 with "dpkg-shlibdeps: error: couldn't find library libc.so.6 needed by debian/snd-hda-tools/usr/bin/hda-verb (ELF format: 'elf32-i386'; RPATH: '')."? | 11:53 |
| diwic | is this something multiarch related? | 11:53 |
| diwic | never mind, got it figured out I think | 11:59 |
| brendand | if glxgears is exhibiting poor performance on my system, is that symptomatic of something? | 12:07 |
| directhex | glxgears is not a benchmark | 12:07 |
| persia | pitti, I don't remember clearly. After looking at the spec again, and language-selector, I *think* that the request is to use ibus-table-zhuyin as a useful option, rather than, or in addition to, the set already in place for zh-han* | 12:17 |
| persia | Err, nevermind. I see what you mean now. I don't see how ibus-table-zhuyin is selected either. | 12:18 |
| brendand | directhex - maybe 'poor performance' is the wrong term. it's somehow using much more CPU than other GL applications | 12:19 |
| persia | freeflying, Do you happen to remember precisely what was desired for Qin and bopomofo ? | 12:20 |
| freeflying | persia: bopomofo is nearly useless to us, try to remove it | 12:21 |
| persia | freeflying, Remove from the archive, or just not present it? | 12:21 |
| freeflying | persia: not present it | 12:21 |
| persia | Do you know how it is presented now? | 12:22 |
| persia | It doesn't appear to be the default anywhere. | 12:22 |
| freeflying | persia: within natty, if you choose chinesee during installation, it will be presented | 12:22 |
| === MacSlow is now known as MacSlow|lunch | ||
| persia | freeflying, Could you file a bug with the precise steps needed to be taken to do that? I can't find anywhere in the code that seems like it should install ibus-table-zhuyin. Alternately, do you expect the issue is more about ibus configuration, rather than about the packages that are installed? | 12:28 |
| freeflying | persia: seems its not from ibus-table-zhuyin, mostly from m17n | 12:34 |
| persia | ibus-m17n ? | 12:36 |
| Quintasan | jono: ping | 12:39 |
| Quintasan | jono: meh, ubuntu-pl has expired from locoteams-approved, can something be done about that the quick way or we need to follow some procedure? | 12:40 |
| persia | Quintasan, You want a member of the LoCo Council for that question: tru #ubuntu-locoteams as a starting point | 12:43 |
| persia | s/tru/try/ | 12:43 |
| persia | freeflying, I'm confused how ibus-m17n even gets installed. To me it looks like zh-hans should always get ibus-pinyin+ibus-table-wubi and zh-hant should always get ibus-chewing+ibus-table-cangjie | 12:46 |
| === zyga-food is now known as zyga | ||
| pitti | freeflying: hm, but we don't install m17n either any more | 12:58 |
| persia | pitti, Looking at language-selector, it seems data/pkg-depends is new for oneiric: what was the equivalent in natty? (I've been looking at the dependencies of binary language-support-input-*) | 13:03 |
| pitti | persia: pkgdepends has been around since maverick or even lucid | 13:03 |
| persia | pitti, As the handler for input methods? | 13:05 |
| pitti | persia: ah, no; in natty we still used language-support-input-* | 13:05 |
| pitti | Package: language-support-input-zh-hans | 13:05 |
| persia | Ah, good, then I've been looking in all the right places :) | 13:05 |
| pitti | Depends: im-switch, ibus-pinyin, ibus-table-wubi | 13:05 |
| persia | Right. | 13:06 |
| pitti | Package: language-support-input-zh-hant | 13:06 |
| pitti | Depends: im-switch, ibus-chewing, ibus-table-cangjie | 13:06 |
| freeflying | pitti: persia I was wrong, bopomofo seems included within ibus-pinyin, lemme double check | 13:07 |
| persia | Ah, so the request is to modify the configuration of ibus-pinyin so that it doesn't default to bopomofo (or bopomofo is hidden by default)? | 13:08 |
| freeflying | persia: hide bopomofo from default | 13:09 |
| pitti | freeflying: the request also includes installing "sunpinyan" by default for zh-hans; is that ibus-sunpinyin? | 13:10 |
| pitti | if so, should that replace the current ibus-pinyin, or be installed in addition? | 13:10 |
| persia | Alternately, is that just a different default for ibus-pinyin? | 13:10 |
| freeflying | pitti: yes | 13:12 |
| pitti | freeflying: "yes" means sunpinyan == ibus-sunpinyin? | 13:12 |
| freeflying | pitti: sunpinyin here means ibus-sunpinyin | 13:13 |
| pitti | thanks | 13:13 |
| pitti | freeflying: should that replace ibus-pinyin, or be in additino? | 13:13 |
| persia | so zh-hans: should specify ibus-sunpinyin+ibus-table-wubi ? | 13:13 |
| freeflying | pitti: ibus-sunpinyin itself perform better than ibus-pinyin | 13:14 |
| freeflying | pitti: but it lacks a configuration tool atm | 13:14 |
| pitti | freeflying: ah, ok; so if we drop ibus-pinyin, and that is the one which pulls in bopomofo, replacing it would also drop bopomofo? | 13:14 |
| freeflying | pitti: yes | 13:15 |
| persia | Heh, and now "replace bopomofo with sunpinyin" makes sense :) | 13:16 |
| freeflying | pitti: is this the plan for oneiric? if so, I will talk to ibus-sunpinyin upstream to see if they can implement the configuration | 13:16 |
| chihchun | No. | 13:16 |
| persia | chihchun, ?] | 13:16 |
| pitti | freeflying: I was asked to do that in https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-qin-ubuntu-china | 13:17 |
| freeflying | pitti: ok, btw, ibus need merged from sid to get gtk3 support | 13:17 |
| pitti | ah, right | 13:18 |
| chihchun | persia: I thought "replace bopomofo with sunpinyin" is plan for general ubuntu installation | 13:20 |
| chihchun | persia: but it's ok for china only. | 13:20 |
| pitti | chihchun: right, this is all per-locale now (zh_CN) | 13:21 |
| freeflying | pitti: #789882 | 13:21 |
| persia | chihchun, It's the expected default for all zh-hans environments. | 13:21 |
| pitti | zh_TW/zh-hant has different ibus modules | 13:21 |
| chihchun | no problem | 13:21 |
| chihchun | understand. :-) | 13:21 |
| persia | chihchun, So, if you're working in zh-hant, you can ignore this. If you think that it makes sense to have bopomofo as default for zh-hans, be prepared to make a very strong argument. | 13:21 |
| pitti | freeflying: ok; seems the biggest thing there is porting the indicator, but that shoudln't be too hard | 13:22 |
| pitti | freeflying: so, we add ibus-sunpinyin and drop ibus-pinyin, which will also get rid of bopomofo; right? | 13:23 |
| freeflying | pitti: to merge from sid, I think indicator's patch still works | 13:23 |
| freeflying | pitti: exactly | 13:23 |
| pitti | freeflying: nah, needs porting to gir1.2-appindicator | 13:23 |
| pitti | freeflying: thanks | 13:23 |
| pitti | but that should be easy | 13:23 |
| persia | The beauty of a 3-character patch :) | 13:23 |
| freeflying | pitti: the only difference between sid and oneiric is gtk3 support, guess we enable it, and add a binary package would be fine | 13:25 |
| pitti | freeflying, persia: ugh, replacing pinyin with sunpinyin would be a + 5 MB compressed size increase :/ | 13:31 |
| pitti | would we actually need to install that on the default ubuntu CDs, or is it enough to have on the Chinese Edition? | 13:31 |
| pitti | cjwatson: ^ do you know? | 13:31 |
| freeflying | pitti: indeed, sunpinyin is statisitical language model based | 13:32 |
| cjwatson | pitti: we're going to have to talk at the rally about localised CD build questions. until then I don't know | 13:32 |
| pitti | well, even the Ubuntu CD will install it when you select Chinese, but would download it from the network | 13:32 |
| pitti | cjwatson: ok, thanks | 13:32 |
| cjwatson | pitti: (because right now the Chinese edition uses the very same livefs and pool as the primary Ubuntu images) | 13:33 |
| pitti | cjwatson: we are going to have an ubuntu-defaults-chinese package anyway (https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-qin-ubuntu-china), perhaps we can build the Chinese edition with that | 13:34 |
| pitti | ok, -> rally | 13:34 |
| cjwatson | I think that would be the idea, yes | 13:34 |
| cjwatson | since all the ubuntu-defaults-* changes are additive, presumably this would still mean that the localised Chinese image wouldn't fit on a CD | 13:36 |
| pitti | yeah, we'd need a separate solution for dropping all other langpacks from that | 13:36 |
| freeflying | ubuntu-chinese-default-settings and ubuntu-chinese-meta hit universe since natty | 13:38 |
| cjwatson | freeflying: that's not what we're talking about | 13:39 |
| cjwatson | https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-cd-localization | 13:40 |
| persia | Where ubuntu-defaults-${LOCALE} just provides localised configuration for default packages, whereas *default-settings provides configuration variables for a flavour? | 13:43 |
| pitti | the package name doesn't have to have any particular form, although ubuntu-defaults-french or derivative-default-settings are the two recommended forms | 13:44 |
| persia | I'd like to avoid the word "derivative" in this context, as it's already overloaded in lots of ways. | 13:44 |
| persia | I'd also prefer to avoid declarations based solely on common language names: should the same values be used in Quebec and France? | 13:45 |
| persia | Obviously, friendly locale names are preferred, rather than "zh_CN" or similar :) | 13:45 |
| pitti | persia: I mean like "mythbuntu-default-settings" | 13:47 |
| cjwatson | I don't see why that's obvious. People get these packages mainly by downloading images, not by selecting the package name for a list. Personally I'd rather that the packages used locale names to keep it simple and avoid collision. | 13:47 |
| pitti | OEM custom projects also use that schema | 13:47 |
| persia | pitti, Ah, sorry. Missed that as a variable. Sure. | 13:47 |
| cjwatson | or will get these packages, anyway, according to the Plan | 13:47 |
| persia | cjwatson, So use the same sort of strings we used for language-support-* ? | 13:48 |
| cjwatson | yep. | 13:48 |
| pitti | well, l-support provided packages for all countries of a particular language | 13:48 |
| cjwatson | but probably with more instances of country codes tacked on the end. | 13:48 |
| pitti | these are not really just language bound | 13:48 |
| persia | Ah, so maybe it is better to use proper locale codes then. | 13:49 |
| freeflying | same scheme like language-support-xx would be clear | 13:49 |
| pitti | if the France loco team wants to do their own image, they'd probably call it -france, but I agree that the standard ll-cc schema avoids conflicts | 13:49 |
| pitti | so we probably should recommend that | 13:49 |
| persia | Or rather, flattened codes (e.g. de_at) | 13:50 |
| persia | Err, "de-at" (_ is prohibited) | 13:50 |
| pitti | and a special -bavaria edition, with a white-blue background by default | 13:50 |
| cjwatson | just use ISO-639-3 for that and call it ubuntu-defaults-bar. :-) | 13:51 |
| pitti | (gotta do somethign with those excess mirror space, bandwidth and iso testing resources..) | 13:51 |
| === kenvandine_ is now known as kenvandine | ||
| persia | pitti, Well, at least the french and japanese teams are likely to prefer their own mirror networks anyway (as they already have infrastructure). Wouldn't surprise me if the same was true for several other locales (with which I'm less familiar). | 13:52 |
| persia | Similarly, many locos are already doing ISO testing for remastered images, so that implies there are resources. | 13:53 |
| pitti | persia: that was the idea indeed | 13:53 |
| pitti | persia: we absolutely don't want to host/test a dozen iso flavour | 13:54 |
| pitti | s | 13:54 |
| pitti | persia: but instead write tools that allow locos etc. to do them on their own with a safe and "approved" set of tools | 13:54 |
| persia | Right. | 13:54 |
| persia | Mind you, I'm all in favour of hosting as many flavours as can justify themselves technically, but I categorically exclude language-specific variants as potential "flavours". This may just be my personal nomenclature though. | 13:55 |
| didrocks | persia: indeed, for the french at least, we have something like 15 mirrors in our infra, so I guess it's better to rely on that | 14:05 |
| didrocks | (some having the official flavors as well, but most of them only hosting our own respin) | 14:05 |
| persia | didrocks, Do you guys do just ubuntu-fr, or also kubuntu,. xubuntu, etc.? | 14:07 |
| persia | We've done kubuntu-jp a couple times, with some interest (with not much overhead over having the first remix) | 14:07 |
| didrocks | persia: we just do that for the ubuntu desktop iso. But we have kubuntu-fr.org and xubuntu-fr.org domain name. Just don't provide a respin (would be too much work) | 14:07 |
| persia | The new tools should help with that :) | 14:08 |
| persia | But it depends more on your testing resources than anything else. | 14:08 |
| didrocks | right, the thing is that we press 10 000 CD of ubuntu desktop respin, we can't do that for kubuntu-fr and xubuntu-fr ;) | 14:08 |
| didrocks | right | 14:08 |
| persia | Oh, certainly. I think the last time we pressed the Japanese remix, it was only 3000 or so, but the other flavours were download only. | 14:10 |
| didrocks | noting that the testing has already limited ressource on our first respin (which is also used for framakey ubuntu-fr remix which is an usb key sharing profiles between windows/mac/ubuntu with portable applications), which is quite scary for the volume of pressed CD/installed usb key we have :) | 14:10 |
| didrocks | but sure that other flavors can come as download only | 14:10 |
| mterry | doko_, ping about deja-dup's MIR (well, really ubuntuone-couch). It's ready to be re-reviewed after converting to dh_python2 | 14:19 |
| === MacSlow|lunch is now known as MacSlow | ||
| === korn_ is now known as c_korn | ||
| === oubiwann` is now known as oubiwann | ||
| === Ursinha is now known as Ursinha-lunch | ||
| === jjohansen is now known as jj-afk | ||
| jcrigby | cjwatson, pitti or some other other TB member I need to get permissions to upload some packages. This was approved on the DMB mtg on 23May and I believe persia sent an email about this yesterday or earlier today. My application is here (it lists the packages) https://wiki.ubuntu.com/JohnRigby/DeveloperApplication-LinaroLinuxAndUBoot | 15:41 |
| jcrigby | also is there a way to check permissions without actually trying an upload? | 15:41 |
| Daviey | jcrigby: Yes, and you currently have no upload access. | 15:43 |
| Daviey | :( | 15:43 |
| jcrigby | Daviey, that is actually not a surprise:) | 15:44 |
| * cjwatson goes to see if that mail is in the mod queue | 15:44 | |
| cjwatson | I don't see any such mail | 15:46 |
| cjwatson | the TB is happy to act when instructed by the DMB but I'd prefer to actually get an instruction from them directly :) | 15:46 |
| cjwatson | let's see, I wonder if I can find the meeting log | 15:46 |
| Daviey | jcrigby: I note that another package set (adding user to lp team) hasn't been actioned yet. So they may be still doing the actions | 15:47 |
| stgraber | cjwatson: http://irclogs.ubuntu.com/2011/05/23/%23ubuntu-meeting.html | 15:47 |
| jcrigby | cjwatson, persia was the chair that day and said yesterday that he would send an email to the TB | 15:47 |
| Daviey | oh wow, i assumed that was a recent meeting. | 15:48 |
| cjwatson | OK, found it now | 15:48 |
| cjwatson | jcrigby: done now | 15:49 |
| jcrigby | cjwatson, thanks! | 15:50 |
| cjwatson | I've also done upload rights for hrw's cross toolchain packages | 15:51 |
| cjwatson | I'm a bit surprised at the backlog there. Perhaps somebody could check whether there are any other things that the TB is supposed to have taken action on? | 15:52 |
| hrw | cjwatson: armhf ones? thanks | 15:52 |
| cjwatson | no, armel-cross-toolchain-base gcc-4.4-armel-cross gcc-4.5-armel-cross gcc-defaults-armel-cross | 15:52 |
| hrw | cjwatson: ok | 15:53 |
| cjwatson | are the armhf ones in the archive yet? | 15:53 |
| cjwatson | or the 4.6 ones? | 15:53 |
| hrw | cjwatson: yes, they are now. I was busy with other tasks to ask for upload permissions | 15:53 |
| cjwatson | if you could give me the source package names, I can add them | 15:53 |
| sarit | the command "/lib/udev/firmware --firmware=/lib/firmware/2.6.39.1/bnx2/bnx2-mips-09-6.2.1a.fw --devpath=/dev" gives libudev: set_loading: error: can not open '/sys/dev/loading'. Any ideas? | 15:53 |
| hrw | cjwatson: armhf-cross-toolchain-base, gcc-defaults-armhf-cross, gcc-4.4-armhf-cross, gcc-4.5-armhf-cross, gcc-4.6-armhf-cross | 15:53 |
| hrw | cjwatson: and same for armel: armel-cross-toolchain-base gcc-4.4-armel-cross gcc-4.5-armel-cross gcc-defaults-armel-cross gcc-4.6-armel-cross | 15:54 |
| cjwatson | oh, looks like the armel bits may have been there already | 15:55 |
| cjwatson | I've added the armhf packages now | 15:55 |
| hrw | thx | 15:55 |
| hrw | cjwatson: I asked TB for most of armel ones in past | 15:55 |
| didrocks | dholbach: can you advise to use debcheckout for http://people.canonical.com/~dholbach/packaging-guide/html/udd-intro.html#getting-the-source please? (see https://code.launchpad.net/~amoog/ubuntu/oneiric/libqtbamf/lp-765915/+merge/65132) | 16:42 |
| slangasek | pitti, seb128: do you know if I should merge pitivi 0.14.0-2 from Debian? I touched it for the dh_python2 migration, now it's under my name on merges.u.c :) | 16:42 |
| seb128 | slangasek, that would be great ;-) should be an easy one | 16:43 |
| seb128 | slangasek, thanks | 16:43 |
| slangasek | seb128: ack - didn't figure the merge would be problematic, but I don't use it so my testing will be non-existant :) | 16:43 |
| seb128 | slangasek, that's fine, I just run it and close it usually to test, we are few changes over debian and nothing likely to break it | 16:44 |
| dholbach | didrocks, could you file a bug on https://pad.lv/p/ubuntu-packaging-guide? | 16:44 |
| didrocks | dholbach: sure :) | 16:44 |
| slangasek | seb128: ok :) | 16:44 |
| dholbach | didrocks, I'm not 100% sure what exactly is the best approach and if it always works, so maybe it's good if somebody else comments on it as well | 16:45 |
| didrocks | dholbach: agreed, I'll link to my discusson on ubuntu-devel mailing list as well | 16:45 |
| dholbach | gracias! | 16:45 |
| * mvo just discovered "gummi" the latex editor | 16:49 | |
| === cking_ is now known as cking | ||
| juliank | mvo: Sounds interesting | 16:50 |
| pitti | mvo: hah, nice name | 16:51 |
| mvo | looking over the new stuff in app-install-data is always fun :) | 16:52 |
| === zyga is now known as zyga-food | ||
| didrocks | I was more found of Kile :) | 16:54 |
| slangasek | cjwatson: so as ev mentioned in the meeting, all the options for updating wubi this cycle seem to imply it won't fit on the CD anymore. Where does that land on our priority list? | 17:08 |
| ev | not all of them. It might be wise to keep the legacy version around, if that's the route we go with. | 17:10 |
| ev | so at least they have *something* on the CD | 17:10 |
| slangasek | ev: a complete legacy branch, or a legacy frontend that's maintained in parallel? | 17:10 |
| ev | a complete legacy branch | 17:10 |
| ev | unless we're still writing python code | 17:11 |
| ev | the wubi code is actually core/ui split | 17:11 |
| slangasek | right; having two completely different branches of wubi would worry me | 17:11 |
| slangasek | doesn't seem sustainable | 17:11 |
| ev | ideally the old one wouldn't break and we wouldn't have to poke it much, other than to update it for new versions of grub and whatnot. | 17:12 |
| ev | that's actually largely been the case | 17:12 |
| ev | we barely touch the UI code these days | 17:13 |
| ev | mind you, I may live in a fantasy land full of rainbows and unicorns | 17:13 |
| slangasek | I've heard that said about London :) | 17:14 |
| ev | lol | 17:15 |
| slangasek | well, we could let wubi drift for a few cycles that way, but I think ultimately we'd wind up with only one of the two well-supported | 17:15 |
| ev | sure, but in a few cycles time hopefully the number of Windows XP users hitting Ubuntu.com will be far, far less | 17:16 |
| ev | or they'll all have .NET 3.5 | 17:16 |
| cjwatson | I think it's still pretty cool for inserting a USB stick into a Windows system to do something useful, although it doesn't have to be the current form | 17:17 |
| slangasek | meaning we'd do *another* rewrite? Or we'd target .NET 3.5 now for the website with the understanding that it's not good enough for the CD? | 17:17 |
| cjwatson | even if it were a shell one of whose options downloaded stuff from ubuntu.com to kick off wubi | 17:18 |
| cjwatson | a bit weird, but ... | 17:18 |
| ev | slangasek: well, we could be fancypants and offer up the legacy version on the website where we can detect a version of .NET older than 3.5 | 17:18 |
| slangasek | hah | 17:18 |
| slangasek | I don't think we'd want that, really | 17:18 |
| ev | and do the rewrite in WPF or whatever Microsoft is pushing on top of .NET these days | 17:18 |
| ev | why not? It's in the user agent string. | 17:19 |
| ev | simple enough | 17:19 |
| slangasek | yes, but then it gives them a crippled experience | 17:19 |
| slangasek | if they're on the website downloading anyway, better to give them the full experience | 17:19 |
| ev | it's better than no experience or a 50MB download before they get an experience | 17:19 |
| slangasek | I'm not convinced the latter is true | 17:19 |
| cjwatson | we haven't touched UI code very much, but I do occasionally have the need to work on the backend Python code; I'd appreciate it if that were at least somewhat accessible to Ubuntu developers who aren't Windows developers | 17:19 |
| cjwatson | e.g. if you're going to use .NET, make sure it works with mono, or something | 17:20 |
| ev | yeah, I was just thinking I should really test that. The .NET 3.5 installation experience when running a WPF application, that is. | 17:20 |
| ev | mono> WPF wont, Silverlight will. | 17:20 |
| cjwatson | didn't moon just get removed? | 17:21 |
| slangasek | ev: I don't want a user to have a completely different experience clicking the "install Ubuntu" link from one XP machine where they happen to have .NET upgraded, than on another machine where they haven't, with no explanation | 17:21 |
| ev | Moonlight? I have no idea. | 17:21 |
| cjwatson | or I'm pretty sure I saw directhex talking about it | 17:21 |
| ev | That would be an interesting development. | 17:21 |
| ev | slangasek: fair point. | 17:21 |
| slangasek | oh hah, that's why no one's complained about the util-linux merge breaking things, it's still in NEW | 17:27 |
| === deryck is now known as deryck[lunch] | ||
| === deryck[lunch] is now known as deryck | ||
| === jj-afk is now known as jjohansen | ||
| === deryck is now known as deryck[lunch] | ||
| hallyn | hm, when i do debuild -S, it gets to telling me what user (mine) it will sign with, but never asks for passphrase | 17:55 |
| hallyn | oh, it's complaining about dead agent | 17:56 |
| hallyn | nm | 17:56 |
| stgraber | @pilot in | 18:02 |
| === udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber | ||
| broder | stgraber: fyi, overlay doesn't support more than 2 branches, unfortunately | 18:03 |
| broder | it just has an "upper" and "lower" branch | 18:03 |
| broder | err, overlayfs | 18:03 |
| hallyn | broder: yeah but you can nest them :) | 18:06 |
| broder | blech | 18:06 |
| stgraber | broder: ok, I guess I'll have to play with that soon... | 18:20 |
| cjwatson | jhunt: I've fixed the priority_list problem you spotted in debconf | 18:33 |
| cjwatson | it only happened if you did 'use Debconf::Priority' under 'use strict' before 'use Debconf::Config' (or something else that used Debconf::Config) | 18:33 |
| stgraber | broder: hey, I'm looking at the SRU for bug 565047 | 18:48 |
| ubottu | Launchpad bug 565047 in initramfs-tools (Ubuntu) "Unable to install off USB 3.0 port (HP Envy 15 Laptop)" [Undecided,Confirmed] https://launchpad.net/bugs/565047 | 18:48 |
| broder | stgraber: yeah, i think the fix in oneiric is still pending | 18:48 |
| broder | last i heard cjwatson was waiting to figure out what was going on with /run before merging the new initramfs-tools | 18:48 |
| stgraber | broder: so apparently debian's initramfs-tools in version 0.99 fixes it but it's not in oneiric yet. Should I just apply the same fix to oneiric for now and upload the SRUs or wait till we get 0.99 in oneiric? | 18:49 |
| === deryck[lunch] is now known as deryck | ||
| broder | stgraber: cherry-picking the commit for oneiric for the time being seems like a good idea, since the /run stuff seems to be a bit stalled | 18:50 |
| broder | i can do the writeup for that in a few minutes if you'd like | 18:50 |
| stgraber | broder: that'd be great. Just let me know when it's done and I'll upload all of that | 18:50 |
| === Ursinha-lunch is now known as Ursinha | ||
| jhunt | cjwatson: thx! | 18:52 |
| broder | stgraber: do you know if the SRU team will still do forward-copies of packages like they do with 0-day SRUs? because that would work here | 19:00 |
| stgraber | broder: I don't think it's part of the official SRU process, at least I noticed quite a few cases where that didn't happen. | 19:01 |
| * broder shrugs | 19:01 | |
| broder | not like the debdiff is hard to put together or anything | 19:01 |
| stgraber | broder: in this case I'd just upload 0.98.8ubuntu4 in oneiric and the exact same thing as 0.98.8ubuntu3.1 to -proposed | 19:01 |
| broder | stgraber: ok, debdiff with s/ubuntu3.1/ubuntu4/ is attached to the bug :) | 19:03 |
| broder | i didn't want to mess with the branch because i don't know what to do with Keybuk's /run change | 19:03 |
| stgraber | broder: ok, I'll have a look. thanks | 19:05 |
| stgraber | broder: hmm, yeah, I'm not entirely sure how to deal with what's currently in the branch for oneiric... | 19:18 |
| stgraber | I don't really want to upload what's in the branch at the moment. I just want to upload the bugfix... | 19:18 |
| stgraber | barry: how should I deal with that? (non-uploaded changes in a packaging branch where I just want to apply a small bugfix but not upload what's currently waiting in there) | 19:19 |
| slangasek | stgraber: I think in general people shouldn't push changes to the official packaging branch before they're ready for upload; is there a reason you don't want to upload those at the same time? | 19:20 |
| slangasek | is the stuff on there right now entangled with /run? | 19:20 |
| stgraber | slangasek: yeah, current content of the packaging branch is the switch from /dev/.initramfs/varrun to /run (changes to the init script and manpage) | 19:21 |
| slangasek | mmk | 19:22 |
| stgraber | slangasek: http://paste.ubuntu.com/630925/ | 19:22 |
| slangasek | what's the current holdup with /run? I thought that was ready to go | 19:22 |
| stgraber | well, maybe it's ready to be uploaded but as Keybuk is a coredev I'd think he'd have uploaded it then. I know that broder's fix won't cause any problem when uploaded to oneiric but I really don't have the same confidence with the /run change :) | 19:24 |
| === yofel_ is now known as yofel | ||
| stgraber | looking at the code currently in the branch, it "seems" good. The only thing I'm wondering is what will happen if /run doesn't exist on the target (as it's currently the case in oneiric) | 19:27 |
| broder | stgraber, slangasek: there was also the change that Keybuk had sitting on top of base-files. initramfs-tools might be good to go if you upload the base-files change first | 19:28 |
| broder | stgraber: yeah, the new base-files creates /run | 19:29 |
| stgraber | broder: where's that code? I don't see any non-uploaded commit in ubuntu:oneiric/base-files | 19:30 |
| broder | stgraber: it got moved out of the way by the package importer: https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/base-files/oneiric-201105041859/+merge/59981 | 19:30 |
| stgraber | hmm, for base-files, shouldn't we instead merge 6.4 from debian that essentially does the same thing ? | 19:35 |
| broder | On upgraded systems, initscripts will handle the transition to /run> seems potentially problematic for us | 19:37 |
| stgraber | I'm almost tempted to just upload broder's fix to oneiric without using UDD. Let the imported move the current changes from Keybuk to another branch as the whole switching to /run thing seems to be a bit more work than what I'm prepared to do when patch piloting :) | 19:38 |
| stgraber | *importer | 19:38 |
| === zyga-food is now known as zyga | ||
| broder | geez. the number of things that change to support /run in sysvinit 2.88dsf-13.3 is terrifying | 19:38 |
| stgraber | I "could" upload base-files with the changes from Keybuk, then upload initramfs-tools with a strict dependency on base-files + broder's fix. But I'm really quite worried I'm going to break a lot of systems just a few days before people go to the sprint... | 19:40 |
| broder | haha, and look what happens if you say "Keybuk" enough times :-P | 19:41 |
| stgraber | hehe | 19:41 |
| stgraber | hey Keybuk | 19:43 |
| stgraber | Keybuk: broder has a simple one line patch to apply to initramfs-tools in oneiric and I noticed you currently have non-uploaded changes in the branch for the switch to /run | 19:44 |
| stgraber | Keybuk: should I move your changes to a separate branch for now and upload broder's fix or are the changes to switch to /run ready to upload? | 19:44 |
| Keybuk | stgraber: oh, yes | 19:51 |
| Keybuk | sorry, I stalled my changes based on things in Debian | 19:51 |
| Keybuk | and didn't back them to a branch | 19:51 |
| Keybuk | so yeah, move my changes out of the way for now | 19:51 |
| stgraber | Keybuk: ok, thanks | 19:52 |
| stgraber | slangasek: what's the best way of doing that? do a direct upload and let the importer deal with it or do a push to another branch, then uncommit, then push overwrite to the packaging branch? | 19:53 |
| slangasek | Keybuk: what's stalled on the Debian side? I thought it was moving along over there | 19:54 |
| slangasek | stgraber: whatever you do, do NOT uncommit - the importer will never forgive you :-) | 19:54 |
| slangasek | stgraber: direct upload + importer dealing seems fine | 19:54 |
| stgraber | slangasek: ok, noted :) will do a direct upload then | 19:54 |
| stgraber | slangasek: AFAICS initramfs-tools, base-files and sysvinit have all been uploaded to Debian | 19:54 |
| stgraber | so unless I missed something, sid should already be using /run | 19:55 |
| Keybuk | slangasek: nothing, I mean I stalled my side when I realised it was already being worked on there | 19:58 |
| slangasek | ah | 19:58 |
| stgraber | broder: uploaded for oneiric, natty-proposed and maverick-proposed. Thanks! | 20:02 |
| broder | stgraber: rock on. thank *you* | 20:05 |
| === Quintasan_ is now known as Quintasan | ||
| === yofel_ is now known as yofel | ||
| charlie-tca | ubuntu-bug xubuntu-default-settings | 22:15 |
| charlie-tca | or | 22:15 |
| charlie-tca | ubuntu-bug xubuntu-meta | 22:15 |
| stgraber | @pilot out | 22:24 |
| === udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!