=== ericrw_ is now known as ericrw === freeflyi1g is now known as freeflying [01:53] dtchen: given the upstart stuff you tried to sort out for alsa-utils, do youf irstly mind if I do that merge, and secondly, do you want me to include those upstart changes you made in the update? === asac_ is now known as asac [02:19] pitti, cjwatson: a little present for you in the -proposed queue (gdm+xorg) [02:26] * cjwatson looks [02:27] slangasek: could you look at lilo-installer in hardy-proposed for me, in return? :) [02:28] slangasek: we don't want to use a respawn limit instead? I thought historically we made the sketchy assumption that gdm might do better a second time, or something [02:30] oh, it respawns itself on a crashing X server [02:32] slangasek: where does EXIT_STATUS come from? [02:33] ha, undocumented upstart feature [02:33] oh, just not documented in init(5), but stopped(7) [02:33] slangasek: what if gdm was killed by a signal (other than the usual termination signals - e.g. SEGV)? [02:58] i was wondering earlier, where the .04 and .10 versioning scheme comes from? [02:58] months of the year [02:58] oh ;-) [02:58] 9.04 == April 2009 [02:58] thanks [03:27] cjwatson: lilo-installer> ack, looking :) [03:29] cjwatson: haven't looked in detail at signal handling; I can dig into that further if you wish, but the major problem is gdm exiting on its own, and I think this upload is a marked improvement regardless of how it handles signals [03:29] cjwatson: btw, I noticed after upload that bryce also had a 7.1 upload to -updates, so I rejected my own ubuntu8 - bryce has merged the two and uploaded ubuntu9 [03:34] TheMuso: I don't mind, and I would like that bit merged, yes. [03:36] dtchen: ok will do, thanks. [03:38] TheMuso: great, thanks [03:39] dtchen: Can you take a look at bug #330766? [03:39] Launchpad bug 330766 in pulseaudio "pulseaudio hangs, prevents login, home as ntfs" [Unknown,Fix released] https://launchpad.net/bugs/330766 [05:03] slangasek: I think it would be worth checking into signal handling some more, yes, but I agree that it makes sense to accept this in the meantime, and have done so [05:03] slangasek: are any corresponding changes needed to kdm? [05:05] cjwatson: bulletproof-x only ever hooked into gdm... we could do kdm as well, but that would involve quite a bit of fiddling and is probably not a good idea for SRU [05:05] thanks for the accept :) === spm changed the topic of #ubuntu-devel to: LP down 0900UTC - 1030 | Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs [05:42] anyone familiar with getting grub2 to boot openbsd and the like? [05:42] i thought a simple chainloader +1 should suffice [06:16] slangasek: ok, I wasn't sure if kdm had hooks or not [06:17] m4t: not familiar with BSD, but I know that GRUB2 has explicit commands for it, which rather suggests to me that chainloader is not sufficient [06:19] m4t: you might try 'help openbsd' in the GRUB shell [06:20] (it'll change to 'kopenbsd' in the future to denote that it's for the openbsd kernel specifically [06:20] cjwatson: is grub2 nice? [06:21] ask a more meaningful question :) I like it, personally [06:21] much nicer to hack on than grub legacy was [06:22] and some day it will free us from menu.lst [06:22] cjwatson: I considered the question carefully :) - and cool [06:22] slangasek: orly? speaking of menu.lst... [06:22] do we know the cause of the missing entries yet? [06:22] some day> I believe the only remaining blocker is sorting out reliable disk identification [06:22] which I've asked Robbie to allocate me a work item for for lucid [06:23] (have already designed it, but regrettably ran out of time in karmic) [06:24] lifeless: I'm attributing it to the unexplained causality bubble that follows you around [06:24] because nobody could reproduce it on a fresh install [06:24] slangasek: and yet, many folk have this problem :) [06:24] slangasek: did the testers try manual partitioning? [06:25] many folk have a problem with the same symptom [06:25] really? you're the only one who's been confirmed to have /this/ problem [06:25] cjwatson: true [06:25] lifeless: did you already attach your installer syslog to a bug? [06:25] cjwatson: yes [06:25] oh yes, I think I looked at it and it was inconclusive [06:25] long term, though, grub2 ought to hook into /etc/kernel/p*.d/ and sidestep this [06:25] I know for a fact that manual partitioning is not fucked in this way, in general [06:25] (there's a bug just opened on the Debian package about that, in fact) [06:26] this is not to say that there are not specific problems [06:26] but it doesn't pay to overgeneralise [06:26] the only cause I can think of for update-grub not getting hooked properly would be the installer crashing before it gets to the end of grub-installer [06:27] sometimes people miss the fact that the installer crashed, assisted by the installer not always being terribly clear about the fact that it crashed [06:27] so they end up continuing to run semi-busted systems [06:27] cjwatson: thats entirely possible [06:27] ok, so I generalised too early I think. [06:27] you might be able to notice this by the fact that, in this scenario, the ubiquity package would be installed on the installed system [06:27] is/was this the case? [06:28] dpkg -l ubiquity -> [06:28] I haven't been on a cleanup crusade that I remember [06:28] the weird bit was that I didn't see any definite indication in your log that grub-installer *had* run properly [06:29] but I'm travelling this week so only had about 30 seconds for analysis [06:29] its : purge ok not-installed in initital-status.gz [06:29] that's fairly indicative [06:29] indeed the fact that you have initial-status.gz at all is a good indication that installation completed successfully [06:30] so, other than I had to manual partition (dmraid system) I don't recall any oddities about the install [06:30] I wonder if something broke kernel-img.conf later, then [06:30] and by manual partition I mean configure dmraid, then run ubiquity and clicky-clicky config the partitions on the dmraid device [06:31] sure [06:31] (no longer necessary in karmic) [06:31] cjwatson: datestamp on kernel-img.conf is 2009-04-21 00:01 [06:31] which is, I think the cd timestamp - there are other directories and stuff in /etc with the same [06:32] it ought to be installation timestamp not cd timestamp [06:32] what's your bug unumber? [06:32] I installed the machine fresh with jaunty [06:32] one sec [06:34] bug 470265 [06:34] Launchpad bug 470265 in grub "[MASTER] jaunty to karmic upgrade failed to update menu.lst (update-grub missing from kernel-img.conf)" [High,New] https://launchpad.net/bugs/470265 [06:38] I don't see it running grub-installer at all there [06:39] that would explain the hook not being present [06:39] OTOH [06:39] how come I can boot? [06:40] you clearly have a bootloader installed, but that doesn't necessarily mean your new installation put it there [06:40] new> the jaunty one I mean [06:40] thats true [06:40] so I bought the machine new [06:41] did you do anything in the advanced dialog in ubiquity, like uncheck the "install grub" box? [06:41] and install a bootloader by hand? [06:41] I don't recall going into the advanced dialog [06:41] that's the only way I can see how this log could have happened [06:41] does ubiquity journal the options? [06:42] if install-grub is off, is the grub package still installed ? [06:42] unfortunately not [06:42] cool [06:42] quite possibly, copied from the live filesystem [06:42] so if I have grub, and didn't manually install it? [06:43] the reason I think you unchecked the option is that the characteristic mount pattern in configure_bootloader is missing [06:43] grub is unconditionally kept installed regardless of that option, but it isn't necessarily installed *as a bootloader* [06:43] right [06:44] I grok the difference :) [06:44] in jaunty, you may well have had to do something like this to make things work with dmraid [06:44] I don't trust my memory of an install 4 months back :( [06:44] ok, so we should close this bug - its not representative I guess? [06:45] please don't close it [06:45] I'm attempting to analyse the cause, not apportioning blame [06:45] even unrepresentative bugs shouldn't necessarily be closed :) [06:46] cjwatson: I get that, but if the cause is 'the user chose not to have grub installed' ? :) [06:46] but then you chose to use it later, and that wasn't handled correctly [06:46] cjwatson: and as grub2 will be less fragile in having the right setting in the hook [06:46] it's still a bug [06:46] k [06:46] I apply a similar analysis to bzr bugs, was really just asking what you wanted [06:46] I don't think that grub2 is less fragile in this particular way (kernel-img.conf), although it is less fragile than others [06:47] cjwatson thanks, uhm, grub shell...is there a grub shell with grub2? [06:47] s/than/in/ [06:47] m4t: the command line when you boot [06:47] ah yea. [06:47] press c at thee menu [06:47] slangasek: is lifeless about the only person who has update-grub just plain missing from kernel-img.conf? [06:48] ehm maybe i am just silly [06:48] # For booting OpenBSD [06:48] menuentry "OpenBSD" { [06:48] set root=(hd0,1,a) [06:48] openbsd /bsd [06:48] } [06:48] from docs/grub.cfg in the latest grub2 source [06:48] I'm wondering if a useful workaround would be to have the kernel packaging explicitly call update-grub if it notices /boot/grub/{menu.lst,grub.cfg} and update-grub isn't in postinst_hook [06:48] what gets me, though... [06:48] is why openbsd refuses to install its second stage loader in the openbsd partition [06:48] slight off-topic but #openbsd doesnt seem very responsive [06:48] let me try with this [06:48] afraid I don't know [06:48] (did grep -ri on the grub2 source) [06:49] er [06:49] grub -ri openbsd [06:49] heh [06:49] please don't use the enter key as punctuation. :) [06:50] cjwatson: so, perhaps fixing the postinst_hook if the grub package is installed and /boot/grub/menu,cfg are present ? [06:50] your menuentry stanza matches the one in up-to-date grub trunk, so I'm afraid I don't know more ... [06:50] lifeless: or just doing the right thing regardless of the dodgy hook thing [06:50] which was (frankly) never a particularly sane design [06:50] cjwatson: or using a dpkg trigger and doing the right thing? [06:51] I don't know whether triggers are the right thing long-term, but I would rather not introduce them in an SRU [06:51] calling update-grub from a new spot might be a problem too [06:52] this wouldn't be a new spot, really - just do it alongside where it already processes postinst_hook [06:52] it's new code, but fewer moving parts [06:52] triggers are cool but they can have some slightly weird consequences sometimes :) [07:08] A lot of free mp3 and video clips. Other pages in social networks "Vkontakte" www.vk.com/reg4286668 and invite your friends! === tkamppeter_ is now known as tkamppeter [07:29] superm1, yay for IRC ping-pong :-/. I completely missed your earlier ping [07:34] Hello, will Source format "3.0 (quilt)" be allowed in lucid ? [07:37] AnAnt: probably, but not for a little while yet [07:46] hello. who handles hal here? [07:47] good morning [07:49] hal stops and doesn't restart when udev is restarted.. hmm [07:52] how does upstart handle "and" and "or" for events? [07:52] does it remember when one event is fired, or what? [07:53] ok [07:54] we've had a lot of bugs lately being filed on ubuntu-docs which are nothing to do with documentation. I'd like to understand why they end up there instead of just without a package allocated. They all say "Binary package hint: ubuntu-docs" at the beginning - does that suggest any explanation to anyone? [07:54] ubuntu-bug ubuntu-docs, perhaps? [07:56] hyperair: I suppose it could be, but I don't see why a user would type that if they have a problem which is nothing to do with docs [07:56] I'm wondering if Launchpad is suggesting the package or something [07:57] agreed =\ [08:00] they type 'ubuntu' and it's early in the list? [08:03] heh [08:04] does launchpad understand the concept of binary packages when it comes to bugs? [08:04] i mean you don't see a launchpad.net/ubuntu/+binary/ do you? [08:04] only in that it can map binary to source when you type a binary package name in the "affected package box [08:05] If you just type "ubuntu" in the search field, it'll tell you there's too many matches. [08:08] ah [08:11] hmm [08:13] a mystery I guess [08:15] you could ask one of the bug reporters how they reported it [08:15] =p [08:19] hyperair: occasionally we do but it's never yielded any results [08:19] heh [08:19] another one of those kinds of mysteries eh [08:19] at one point of time, #ubuntu-sg was getting a lot of people connecting to it from US, UK among other faraway places [08:20] they'd connect when everyone was sleeping, start kicking up a big fuss about how nobody's around to help them and leave before anyone woke up =.= [08:29] Good morning [08:29] kirkland: hi [08:30] kirkland: will process SRUs this morning (as every morning, afternoon, and evening nowadays :) ) [08:38] ttx: any chance to give euca some testing with the packages in -proposed? (see bug 461090) [08:38] Launchpad bug 461090 in libxstream-java "updates for karmic and lucid needed to get maven plugins building" [Medium,Fix committed] https://launchpad.net/bugs/461090 [08:38] ttx: I'll also do a binary debdiff to ensure that the only thing that changed is the added .pom files; but better be double-sure.. [08:39] pitti: sure [08:39] pitti: I need to purge my inbox first, but i'll update my setup to -proposed and run a few tests soon [08:40] ttx: merci beaucoup! [08:40] pitti: bitte [08:51] cjwatson: lifeless is the only one w/ a botched kernel-img.conf missing that I've run across /so far/. === kklimond- is now known as kklimonda [09:14] argh, LP offline [09:15] pitti, hey, same here [09:15] I could have slept an extra hour ;-) [09:18] weird, I didn't read any mailing list announce about it [09:20] seb128: there was one yesterday [09:20] wgrant: FYI, something like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538679#10 is now sent to quite a lot of packages, so I think we won't get around having dpkg-3.0 in lucid :-( [09:20] Debian bug 538679 in dclock "dclock: FTBFS with new source format 3.0 (quilt): removes .pc before quilt pop" [Wishlist,Open] [09:21] pitti: We certainly won't get around it for Lucid. [09:22] pitti: The thing in question is whether we can get away without it until 2009-12-05. [09:22] * wgrant checks the rate of 3.0 migration. [09:22] wgrant, what is special at this date? [09:23] next scheduled lp rollout? [09:23] seb128: LP 3.1.11. [09:24] oh ok [09:24] We have the option of cherrypicking before then though, since the DB changes slipped into 3.1.10. [09:52] hi all, I would like to help with these new problems of the upgrade [09:52] I am a developer, and can do all types of things. [09:53] right now I have upgraded my ubuntu from 8.4 over the months [09:53] and the sound and netowork stopped working [09:53] is there anything that I can do to fix this? [10:03] ok well i will file a bug report [10:25] Hello, is it possible to build a Source format "3.0 (quilt)" package on my karmic installation ? [10:25] using pbuilder that is [10:30] AnAnt: the dpkg in karmic supports it if you pass some magic options (which I don't know offhand); Launchpad won't currently accept any such packages though, FWIW [10:30] Phurl: filing a bug report sounds like a good idea there [10:31] ok [10:32] It shouldn't need magic options besides the existence of debian/source/format. [10:33] oh, well, that's magic enough :) [10:35] wgrant: so, does one still need to put quilt in build-deps ? [10:35] if he is using quilt patch system that is === mthaddon changed the topic of #ubuntu-devel to: Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs [10:44] * StevenK blinks at why his shiny new Dell doesn't want to talk via Ethernet [11:06] pitti: Oh, I wanted to talk to you about one of your specs? [11:06] StevenK: please do :) [11:07] pitti: You subscribed me to the UNR session one so that desktop people could try it? [11:07] pitti: I was wondering if we could also do it the other way -- if the UNR session was the default for UNR images, but people could choose a desktop session too [11:16] Oh, duh. Don't play with Jockey when apitude is installing stuff [11:16] pitti: But Jockey could give a better error than "installArchives() failed" [11:18] StevenK: that should be easy as well [11:18] pitti: If you're happy to cover that in the spec, then that is one less I have to write :-) [11:18] StevenK: sorry, had a DSL reconnect; I got your "Oh, duh...", but not anything before that [11:18] [22:07] < StevenK> pitti: You subscribed me to the UNR session one so that desktop people could try it? [11:18] StevenK: it'd be a separate package though, I guess [11:19] [22:07] < StevenK> pitti: I was wondering if we could also do it the other way if the UNR session was the default for UNR images, but people could choose a desktop session too [11:19] [12:11] pitti| StevenK: that should be easy as well [11:19] pitti: Right, then you were answering what I thought you were. :-) [11:20] StevenK: can be covered in the same spec; it's the same scheme, just a different package and session name [11:20] pitti: Can you also subscribe davidm to the spec? [11:20] * StevenK digs for it [11:21] StevenK: done [11:21] StevenK: please change the summary accordingly (how you want it to look in UNR, since you don't have gdm visible) [11:23] pitti: We still use gdm, so it could be hand waved, I guess === ara_ is now known as ara [12:26] amitk: if you have a moment I would like to ask about bug #453444 - is the kernel in karmic-final fixed or is this a fix that is commited and will be part of a commin update? [12:26] Launchpad bug 453444 in rsyslog "/var/log fills up with "all normal" messages @ about 575/sec fill up the available space" [High,In progress] https://launchpad.net/bugs/453444 [12:26] amitk: I ask because I got reports (eg. from YokoZar) that this is still a problem with karmic-final [12:39] pitti: hm, there is a discussion on flag-restart-required *before* actually doing the upgrade in update-manager. what do you think about "XB-Restart-Required: [system, session, app]" in debian/control ? [12:40] mvo: oh, instead of having to change the postinst? sounds nice [12:40] yeah [12:41] nice and simple, I'm trying to think of downsides, but I can't see any [12:41] mvo: before the upgrade> so that the user can choose not to do it right now? [12:41] yes [12:41] mvo: which bit would check that flag and call restart-required? dpkg? [12:41] showing in u-m "this update requires a restart" [12:41] well, I was not thinking that far :) [12:42] we could have a debhelper thing that generates a postinst just like we have now [12:42] or that [12:42] or modify dpkg/apt/apt-listchanges [12:42] mvo, what do you want to do from this info? [12:43] mvo: would it be able to specify versions as well? [12:43] seb128: showing in update-manager "2 updates that require a restart" [12:43] XB-Restart-Required: system (<= 0.1-1) [12:43] mvo, is that a "you need to restart to be able to use the upgrade" or a "you should restart because you don't get the security fix until then"? [12:43] james_w: sweet, that is a nice idea [12:44] some packages do dpkg --compare-versions currently in the postinst? [12:44] james_w: Meaning "if you're upgrading from a version of this package earlier than 0.1-1, you need to reboot"? [12:44] seb128: I'm not sure I understand the difference, but it would be purely to show the user in advance that this update will require some sort of restart (e.g. fireofx) [12:44] soren: exactly [12:44] james_w: Ok. [12:45] for those packages that don't require a restart every time they are upgraded [12:45] mvo, the difference: is it to point cases where the upgrade will break what you do and force you to restart? [12:45] mvo, or is that for things like dbus or you are suggested to restart [12:45] james_w: I wonder if there are any currently (but its good to have the feature) [12:45] of course, it can always be more complex, like "restart if this other package is installed", but you can always suggest restarting too much [12:46] mvo: what would signal update-notifier? [12:46] seb128: currently its mixed together, it might make sense to have a different one. like restart-suggested, restarted-required [12:46] mvo: would dpkg now write the /var/run/ file based on XB-Restart-Required? [12:46] james_w: not sure yet, it could either be the currently mechanism and debehlper would do some magic [12:46] well, it's not really "suggested" [12:46] ok [12:46] james_w: or we move it to dpkg or we add a pre-run hook [12:46] the difference is just that ffox breaks after the upgrade, while dbus doesn't [12:47] (like apt-listchanges, just for this) [12:47] pitti, well I think the user is rather interested to know about things which will break [12:47] pitti: yeah, for the "it-breaks" it would be a "restart-required: app" [12:47] seb128: exactly [12:48] restart-requires: [system, session, app, app-breaks] ;) [12:48] app and app-breaks is the same [12:48] you only want to notice about breakages [12:48] you can assume than in any case you need to restart an app to get the change anyway there [12:49] good point [12:49] in any case seems fine to me [12:49] +1 [12:49] we can figure what we do from the info later [12:49] How about something like this: We add the field (as an XB-Restart-Required), and add a debhelper script that detects it and adds a handler to postinst. The handler will dump the information in a state directory somewhere, and call "dpkg-trigger restart-required". [12:49] Packages like update-notifier can add a handler for that trigger and do somethign useful with it. [12:50] soren: that sounds like a good plan, I think we have just create a mini-spec :) [12:50] NCommander, if we are on different time zones right now, email might be better then [12:50] That way, we don't need extra magic in dpkg at all, and we have flexibility in adding multiple handlers. [12:50] thanks seb128, pitti, soren, james_w [12:51] soren: yeah [12:52] soren, mvo: right now the script/inotify ensure that dpkg is completely done; with a trigger, the user might click "reboot" too early (e. g. when a later trigger is still doing stuff)? [12:53] superm1, we're in relatively close timezones. The problem is my internal body clock thinks its in Japan at the moment [12:53] pitti: Depends. [12:53] pitti: Whatever is triggered can check if the package db is still locked. [12:53] Or whatever. [12:53] pitti: It's definitely solvable. [12:53] ah, fork & poll FTW :) [12:53] Well, in the case of update-notifier, doesn't it just send a dbus event that something else will handle? [12:54] soren: solvable> agreed, just needs to be kept in mind [12:54] * soren hasn't really looked closely at that stuff. [12:54] pitti: Sure. Good point. [12:54] * mvo nods [12:54] soren: no, u-n inotifies a flag file that /usr/share/reboot-required script sets [12:54] and then waits on apt to finish [12:54] The thing that actually suggests to the user to reboot should be smart enough to not do this if e.g. the package db is locked. [12:55] pitti: Ah, ok. [12:55] soren: but you are right; we clearly need to involve d-bus here! :-) [12:55] So if someone starts apt again in the mean time, what happens? [12:55] soren: after the upgrade? you lose [12:55] NCommander, okay well what's up? [12:55] does the restart dialog disappear.. [12:55] oh. [12:55] i. e. if you start another install and click reboot [12:55] well, that should probably be fixed, too :) [12:55] superm1, mind if I PM you? [12:55] sure [12:56] I think what we want is a more general "if you reboot while dpkg is running, give it a bit extra time to finish". but that becomes tricky when the user is e.g. in a hurry [12:56] its also a problem in how to represent it [13:00] mvo: As a first step, how about just having the UI not offer the option to reboot if dpkg is running? [13:01] * soren runs an errand [13:02] soren: that should already be the case, but it should also auto-vanish if dpkg gets started again after the dialog was shown [13:03] mvo: ..and turn up again when dpkg is done, surely? [13:03] yes [13:03] Ok. [13:03] Great :) [13:03] :) [13:03] mvo: one thought [13:03] just the vanish-again part needs to get done, then its cool [13:04] does "XB-Restart-Required: package" depend on whether it is an upgrade or install? [13:04] would we have anything that needs to trigger a restart when installed for the first time? [13:04] hm, in the case of an app not, but in the case of a kernel it might be I think [13:05] because you could force only-on-upgrade with "XB-Restart-Required: package (>= 0)" [13:05] or of e.g. a nvidia driver, a session restart is suggested then [13:05] right [13:05] but it may not be possible to force only on install [13:05] so "XB-Restart-Required: package (install)" [13:05] could be supported or something [13:05] depending on what "XB-Restart-Required: package" alone means [13:06] I think its something to keep in mind [13:06] I don't mean "package" do I? I mean "system" [13:21] dholbach: hi, I've noticed, that you fixed some bugs in msttcorefonts package few years ago, now this package has very big problems, which doesn't allow smootly upgrade to Ubuntu 9.10 (Karmic) :( [13:21] Look at bug #464422 - about 60 duplicates already, about 10 duplicates are reported every day since release of Karmic :( [13:21] Launchpad bug 464422 in baltix "package ttf-mscorefonts-installer 3.0 failed to install/upgrade" [Undecided,New] https://launchpad.net/bugs/464422 [13:24] I think Ubuntu developers should release a fixed version of ttf-mscorefonts-installer ASAP, it's not hard to fix this bug - ttf-mscorefonts-installer shouldn't return an error if there are no access to corefonts download servers, AFAIK a dialog with buttons "Try again" and "Download later" (run dpkg-reconfigure ttf-mscorefonts-installer when you will have internet connection) should be displayed instead === MacSlow is now known as MacSlow|lunch [13:25] "download later" shouldn't result in the package being configured [13:25] the flash installer did that for the longest time, and people ended up with no flash plugin on their systems and no idea why [13:26] Should multiverse be enabled during install??? [13:26] Like slangasek says, there are other packages downloading non-free stuff and that is bound to screw up [13:28] Perhaps downloading packages should be moved to a different component alltogether [13:28] not really [13:28] slangasek: not really what? :) [13:28] they shouldn't be moved to a different component [13:29] making new buckets doesn't change the underlying problem === tseliot1 is now known as tseliot [13:29] slangasek: it does, because you can disable the bucket during upgrade [13:30] but we don't want people not upgrade parts of their system. :) [13:30] +to [13:30] slangasek: in any case - user should get interactive dialog instead of canceled Ubuntu upgrade procedure. Please read the description of bug 464422 - there are lots of situations, when internet connection is lost after packages are downloaded (in configuration stage), so, ttf-mscorefonts-installer shouldn't fail silently if there are no access to download servers [13:30] Launchpad bug 464422 in baltix "package ttf-mscorefonts-installer 3.0 failed to install/upgrade" [Undecided,New] https://launchpad.net/bugs/464422 [13:30] slangasek: that's what's happening anyway, in these bugs [13:31] slangasek: besides, when the bucket is disabled, the system doesn't know that it's supposed to upgrade something :) [13:31] mok0: giving them a button to click that lets them defer the upgrade indefinitely isn't a good solution, though. [13:31] slangasek: I agree [13:32] jdstrand, hi, if you do a sru on a desktop package where the karmic and lucid version are the same please commit to bzr too [13:33] mantiena: right, the package should at least make it clear why it's failing [13:33] jdstrand, not sure if you forgot for evince or if the policy was not clear about where the store sru changes [13:33] slangasek: what about moving fonts download to preinst script? [13:33] that would only change the type of error you get [13:33] jdstrand, I've fixed it in bzr now so no need to look at this one btw ;-) [13:34] slangasek: but if preinst will fail, then ttf-mscorefonts-installer will be left in older version and upgrade procedure will continue, right? [13:35] preinst script could check that the box is connected to the internet [13:35] because currently ttf-mscorefonts-installer is updraded and status is partially installed if there are no access to download servers [13:35] mantiena: I'm not sure how far it will continue, mvo would know better. In both cases, apt will see an error, and eventually report it to the user [13:35] mok0: why? that doesn't change anything about what the script needs to do [13:35] slangasek: ... you're right [13:35] can't download --> failure [13:36] slangasek: it just seems wrong to me somehow to download in preinst [13:37] well, I tend to agree; but for ephemeral, aesthetic reasons - whatever works best must be the right thing to do ;) [13:37] heh, yes [13:37] but if you mean checking for internet connection in the preinst, so we can abort early; but only download in the postinst - this is obviously not atomic, so the preinst check would then be redundant [13:37] slangasek: AFAIK the best situation would be: if there are no access to corefonts download servers, then ttf-mscorefonts-package should be not installed (or not upgraded) and don't return a critical error (distribution upgrading should continue) [13:38] Sort-of when the upgrade of a package requires the installation of a new package, it's left un-installed [13:38] distribution upgrading should continue anyway; if it doesn't, I think this is an issue with package manager error handling, TBH [13:40] checking internet connection in preinst isn't good decision, because there are plenty of cases, when internet connection is ok, but fonts can't be downloaded from some download servers (for example because of timeouts of lots internet connection during download) [13:40] In any case, this package should have no reverse dependencies, and should have the lowest priority of all -> installed at the very end [13:41] slangasek, mok0: in reality updrading ttf-mscorefonts-installer shouldn't download any files from internet, because fonts files are already installed in user's system ;) [13:42] heh, I think that's a separate bug from what we've been talking about so far, then. :) [13:42] mantiena: Indeed [13:43] Why hasn't this been a problem with earlier releases? [13:45] seb128: ack. I was thinking lucid was different now, so didn't commit to bzr. your policy makes sense and I'll keep that in mind going forward. thanks for taking care of the commit, and sorry for not committing [13:45] jdstrand, thanks ;-) [13:53]