[10:14] <Twisterss> Hello everyone, I work on Jolicloud and try to adapt a bit ubiquity, and I just discovered that ubiquity includes a cache of the Release files of the ubuntu repositories during install (in d-i/source/apt-setup/apt-setup-signed_release) and I don't understand how it works.
[10:15] <Twisterss> As this is an old release files, aren't all checksums wrong ?
[10:52] <Twisterss> I don't understand because with an unmodified version of ubiquity, the only cached Release file is archive.ubuntu.com. The installed servers are fr.archive.ubuntu.com, so the cached Release file isn't used. I have just modified the way for ubiquity to get the codename of the release, and now it caches the Release file of fr.archive.ubuntu.com, that is used. So I get a "Hash Sum mismatch" error when I run apt-get
[11:00] <cjwatson> Twisterss: it doesn't matter that the old checksums are wrong, it just has to have been a valid signature at some point
[11:01] <cjwatson> Twisterss: the point of shipping a signed Release file from the start is that that means that apt will always require a signed Release file from that point onward (you can't downgrade from signed to unsigned)
[11:01] <cjwatson> Twisterss: this prevents man-in-the-middle attacks on the archive
[11:02] <cjwatson> I forget how it works for mirrors, but I thought I'd considered that
[11:02] <cjwatson> that may be a bug :)
[11:04] <cjwatson> generators/50mirror.ubuntu does 'apt-setup-signed-release archive.ubuntu.com "$file"'
[11:04] <cjwatson> so that should be fine surely ...
[11:04] <Twisterss> cjwatson: but then it should download again the Release file when you run sudo apt-get update, and I have a problem with that: it never downloads the files unless I manually clear the cache, and I get a checksum mismatch when running apt-get update
[11:05] <cjwatson> that's the sort of thing that often arises from buggy "transparent" web proxies
[11:06] <cjwatson> I've seen that problem for other reasons; are you sure you're correct in ascribing it to apt-setup?
[11:08] <Twisterss> I have no web proxy, and I didn't have this problem until I modified just two lines in ubiquity to change the way ubiquity gets the release codename (it reads a file instead of using lsb-release, because my release name is Jolicloud robby and I still use Ubuntu jaunty repositories)
[11:09] <Twisterss> cjwatson: my changes:
[11:09] <Twisterss>  
[11:09] <Twisterss> -if CODENAME="$(lsb_release -cs)"; then
[11:09] <Twisterss> -	# TODO cjwatson 2006-04-07: wrong for Debian, I think
[11:09] <Twisterss> +if CODENAME="$(cat '/etc/upstream-release/codename')"; then
[11:09] <Twisterss>  	db_set mirror/suite "$CODENAME"
[11:09] <Twisterss>  	db_set mirror/codename "$CODENAME"
[11:09] <Twisterss> +else
[11:09] <Twisterss> +	if CODENAME="$(lsb_release -cs)"; then
[11:09] <Twisterss> +		# TODO cjwatson 2006-04-07: wrong for Debian, I think
[11:09] <Twisterss> +		db_set mirror/suite "$CODENAME"
[11:09] <Twisterss> +		db_set mirror/codename "$CODENAME"
[11:09] <Twisterss> +	fi
[11:09] <Twisterss>  fi
[11:09] <Twisterss> dans scripts/apt-setup
[11:10] <Twisterss> this is the only file I have changed in ubiquity
[11:12] <cjwatson> I'm not sure what your problem is then, sorry
[11:12] <Twisterss> no problem, thank you for the help :)
[11:13] <cjwatson> I'd be happy to look at full logs if you want to file a bug report and attach them
[12:25] <Twisterss> I think I understood my problem: to refresh its cache, apt uses a if-modified-since HTTP header, and sets it to the date when the cached Release file was last modified. But when ubiquity installs the file, the date is the date when I created my ISO, so it thinks that the Release file is good, while it isn't. But I don't understand why I just discovered this problem.
[12:35] <Twisterss> Ok, I understand: when I downloaded the sources of ubiquity, the modification date has been set to the current date, so my package is wrong. cjwatson: Do you have a script to automatically refresh all Release files in ubiquity?
[12:51] <Twisterss> ok, you probably never refresh them as this is just to ensure that it is signed. So I just changed the modification date to an earlier date with touch. I think it will fix my problem :)
[12:54] <Twisterss> (this is a big trap for people trying to build the ubiquity package, though)
[13:12] <cjwatson> Twisterss: I'm surprised the modification date is changed; generally our tools are careful to avoid that
[13:12] <cjwatson> Twisterss: how did you fetch the sources?
[13:13] <cjwatson> -rw-r--r-- cjwatson/cjwatson    189 2009-05-04 15:13 ubiquity/d-i/source/apt-setup/release-files/archive.ubuntu.com/jaunty-proposed/Release.gpg
[13:13] <cjwatson> -rw-r--r-- cjwatson/cjwatson  41698 2009-05-04 15:13 ubiquity/d-i/source/apt-setup/release-files/archive.ubuntu.com/jaunty-proposed/Release
[13:13] <cjwatson> (that's from ubiquity_1.13.4.tar.gz)
[13:14] <Twisterss> yes, but I did a cp :/
[13:14] <Twisterss> (without -a)
[13:15] <cjwatson> don't do that then :-)
[13:15] <Twisterss> I won't do it again ^^
[13:16] <cjwatson> I don't think it's all that big a trap; mostly people will just use 'apt-get source ubiquity' which won't have this problem
[13:16] <cjwatson> but you know now :)
[13:16] <cjwatson> I'll think about whether it's possible to have some safer annotations in the source package to avoid this
[13:51] <Twisterss> I saw a small bug in the ubiquity source code: the window icon of Ubiquity is hard-coded as the icon in /usr/share/pixmaps, you can't override it with a theme.
[13:56] <cjwatson> please do file a bug about that
[13:57] <cjwatson> IRC is not really all that great as a bug tracker :)
[14:00] <Twisterss> ok
[16:17] <CIA-5> base-installer: cjwatson * r373 new-pae-naming/ (13 files in 3 dirs): Adjust for new PAE kernel package naming on i386.
[19:46] <kirkland> fyi, i just tried today's daily karmic amd64 server install
[19:46] <kirkland> default options
[19:46] <kirkland> appears i'm hung at grub
[19:52] <kirkland> hmm, i could be wrong
[19:52] <kirkland> now it's booting
[19:52] <kirkland> there was like a 5 minute delay
[20:02] <cody-somerville> cjwatson, Why doesn't oem-config-udeb get installed by anna automatically like oem-config-check does? (ie. oem-config-udeb seems to only get installed if oem-config-check tells anna to do so in a debian-installer-startup.d hook).
[20:03] <cody-somerville> cjwatson, Is it because oem-config's source package priority is extra and oem-config-udeb doesn't set its own priority to standard like oem-config-check does?
[20:12] <kirkland> cjwatson: default server karmic install, user is not in the admin group
[20:12] <kirkland> cjwatson: known issue?
[20:42] <CIA-5> usb-creator: rgreening * r114 usb-creator/usbcreator/ (backend.py kbackend.py kde_frontend.py): (log message trimmed)
[20:42] <CIA-5> usb-creator: Fix persist calculation in backend.py/kbackend.py
[20:42] <CIA-5> usb-creator: Remove try/except block from update free (was a temp test/fix) in kbackend.py
[20:42] <CIA-5> usb-creator: dd_status needs to know the pid rather than rely on using pipe.pid directly
[20:42] <CIA-5> usb-creator: new kde_frontend function (read_line) for reading source process input
[20:42] <CIA-5> usb-creator: remove subprocess.Popen call (implement via new kde_frontend background_process function)
[20:42] <CIA-5> usb-creator: implement kde_frontend add_io_watch to replace gobject.io_add_watch in kbackend
[21:26] <jsteel> Im trying to install 9.04 on my new core i7 servers. Unfortunately the server edition cant detect my hard drives and gives me an empty list at the partition menu. Desktop edition can see the drives fine though. Does anybody know what the difference is in the two installers and how I can either user the desktop on for the server install, or fix the server install?
[21:33] <cody-somerville> Does partman support creating partitions of type "Dell Utility"?
[21:35] <cody-somerville> superm1, do you know?
[21:38] <superm1> cody-somerville, depends on what you need to create out of it.  they are inherently fat16 partitions
[21:38] <superm1> but there are parts of data in there that are not representable in fat16 that can't be written by open source tools (tied tightly to dell factory)
[21:42] <cody-somerville> superm1, Well, I'm looking to dd in utility partition from Dell so I assume I need it to be an actual dell utility partition type for it to work all fine and dandy.
[21:43]  * cody-somerville goes for dinner, ttyl
[21:45] <superm1> ah, well if partman doesn't already support creating such a partition type, you should be able to write a fairly small patch to do so. just use fat16 on the backend for the patch, but set type 'de'.  since you'll be DD'ing it at the end anyway in a post install script, that should be fine.
[22:06] <CIA-5> usb-creator: rgreening * r115 usb-creator/usbcreator/ (kbackend.py kde_frontend.py):
[22:06] <CIA-5> usb-creator: Move self.pipe from kbackend.py to frontend and provide accessor methods to the process pipe
[22:06] <CIA-5> usb-creator: via get_process_pipe() and the pid via get_process_pid(). The background process needs to be
[22:06] <CIA-5> usb-creator: completely encapsulated in the frontend (since we use KProcess which is toolkit dependant).
[22:06] <CIA-5> usb-creator: Fix all calls referencing self.pipe, self.pipe.pid to use the new accessors.
[22:06] <CIA-5> usb-creator: add_child_watch should pass a pid and not pipe
[22:06] <CIA-5> usb-creator: backend.abort no longer need to have pid passed to it, as it now can use the accessors
[23:41] <xivulon> I am moving wubi to grub2, have only done the windows side, so things will probably be broken until update-grub is also updated
[23:56] <xivulon> TheMuso, when you have time can you check the accessibility page of wubi and please let me know (as in post a bug) if it needs to be changed?