- Arch-releng - lists.archlinux.org

[arch-releng] dialog sizes in archlinux-installer / aif
by Dieter Plaetinck 07 Mar '09

07 Mar '09

Hi all, A purely cosmetical issue, but something that I want to address: the sizes of dialog boxes in aif current approach in aif: some hardcoded values in the revelant functions of lib-ui. problem: for some dialogs they look good, for others they are waay to big (if you've played with aif you may have noticed this already), and hardcoding values is bad practice anyway. Dialog seems to have an "auto sizing" (just fill in 0 as height/width/.. parameter) feature which seems to work quite well: it makes sure what you want to display fits in the dialog and there is some extra padding space so it looks good, so I think I should use this. However, the old installer ( http://projects.archlinux.org/?p=installer.git;a=blob_plain;f=setup;hb=HEAD ) seems to make use of the autosizing often, but also often it still uses hardcoded values. Is there any specific reason for this? Can things go "wrong" by just relying on auto-sizing everywhere? Also, dialog provides an --aspect parameter to control the aspect when using autosizing, however I don't see the need for this. without it, dialog always makes sure the content fits nicely. Even more, I noticed that even when you use extreme aspects (--aspect 1 or --aspect 500), it still shows your content nicely (even if it's for example one long line), looks to me like it doesn't even do much? Dieter

2 2

Re: [arch-releng] AIF [PATCH 1/2] Fix URL parsing for core repo
by Gerhard Brauer 07 Mar '09

07 Mar '09

Am Montag, den 02.03.2009, 06:25 +1000 schrieb Allan McRae: > Gerhard Brauer wrote: > > Dieter, have you seen the attachements (git patches) on both of my > > mails? In sent folder the have the attachements, but my mails getting on > > the ML i don#t see the attached files... > > > > I didn't receive the patches either. You might want to look into "git > send-email" so thing are sent inline rather than as attachments. It > makes commenting on patches a lot easier. Ok, i will have a look at. But i have sent often patches as attachemnts to the list, without any problem. Something changed in the mailing list software so that not all mime files are allowed? (I sent the mail again to my address to see if i made a mistake, but there not problem with the attached patch..) But i will sent them inline again.... > Allan Gerhard > > >

3 3

[arch-releng] AIF [PATCH 2/2] Already running dhcpcd is not stopped during network setup
by Gerhard Brauer 07 Mar '09

07 Mar '09

If network is already set up during ftp install (dhcpcd already running and $INTERFACE is running) aif failed when stopping and reconfigure during interactive network setup. Reason: we kill a process named dhcpd, but it must be dhcpcd. So no running dhcp client is stopped and the network setup failed cause already a client running on $INTERFACE. So we have to kill: kill dhcpcd. Or better use the dhcpcd function fur such a case: dhcpcd -k $INTERFACE. Regards Gerhard

5 8

[arch-releng] AIF [PATCH 1/2] Fix URL parsing for core repo
by Gerhard Brauer 02 Mar '09

02 Mar '09

When doing ftp install method the selected mirror URL is badly parsed to the generated /tmp/pacman.conf. So fetching the core db from mirror fails. Example: [gerhard@ws01 ~]$ serverurl='ftp://ftp.he.de/mirror/$repo/os/i686' [gerhard@ws01 ~]$ echo $serverurl ftp://ftp.he.de/mirror/$repo/os/i686 [gerhard@ws01 ~]$ repo=core old code: --------- [gerhard@ws01 ~]$ echo "Server = ${serverurl/\/\$repo\//\/$repo\/}" Server = ftp://ftp.he.de/mirror\/core\/os/i686 patched: [gerhard@ws01 ~]$ echo "Server = ${serverurl/\$repo/$repo}" Server = ftp://ftp.he.de/mirror/core/os/i686 Cause this code section is commented already as a "hack" maybe it's better to have a solution where we split the $serverurl to get only the absolute mirror URL path (ex: ftp://ftp.he.de/mirror) and build from that our download line for the core repo (ex: "$url/core/os/$ARCH), so we avoid regexe's. Only the core repo needs a "extra" handling, all other repos (if there are any!) uses the pacman.d/mirrorlist method. Regards Gerhard

4 7

[arch-releng] Dates, times, timezones.
by Dieter Plaetinck 27 Feb '09

27 Feb '09

Hi all, Some people have reported issues with the way we do time/date/timezone stuff. most of them are already fixed but we still have 2 open. (http://bugs.archlinux.org/task/12933, http://bugs.archlinux.org/task/13196) One of the issues is cosmetical, the other functional. I would like to implement this correctly so now is a very good time to all think about how time _should_ be handled, and since I'm not an expert in this, I need your advice. A good starting point would be Gerhard's excellent comment from http://bugs.archlinux.org/task/12933#comment40281 I'll quote it here and add my thoughts below. =========== QUOTE Gerhard ================= +1 for using a own dialog for timezones. We should avoid each tool which changes the time during any selection - until we wan't to change it. tzselect for ex. changes the time when selecting a timezone (this is bad cause the hwclock and system time is mostly correct after a boot). Same when copying timezone files to /etc/localtime. But when one only set and export TZ with his timezone then the system time is kept and only displayed with correct timezone value. 2009.02 time/date setting (in installer) is IMHO better than 2008.06 (tzselect, "hardcoded" timezone was CDT IMHO), but not optimal. In 2009.02 timezone was UTC after boot which is IMHO optimal for all installations. What times have we after booting the live/install ISO? 1) hwclock a) BIOS datetime is correct and set to localtime, or b) BIOS datetime is correct and set to UTC, or c) BIOS datetime is not correct 2) system time (this is interpreted with the timezone, first with UTC) a) date shows false time when 1.a is given (localtime vs. UTC). Could be corrected when setting/exporting TZ with correct value, but we should avoid using tzselect or copy a timezone to /etc/localtime cause this *changes* the time value! but we need only a different interpretation) b) date shows correct time when 1.b is given (hwlock UTC vs. date with UTC). When a user would change UTC to his local timezone then also the system time value (not the hwclock) must be changed. Here this is could be done ex. with tzselect tool or copying timezone file to /etc/localtime, but better do this in a own step. c) date shows false time when 1.c is given (all clocks wrong). For this (and as a fallback) we should have a step where a user should be able to set the timezone and value by hand/dialog, with this values we modify system time(date) and BIOS clock(hwclock). So what's our steps for timesetting? Ideally we never would have any problem when users would set HWCLOCK and TIMEZONE in bootloader as boot parameters ;-) But if a user boot boot the cd without these in Peking, Chicago or Brussel we must ask him some questions: a) Is your hardware clock set to localtime or UTC? b) Based on this answer whe should present the output of date or date -u c) Ask him: Is this the correct time displayed also on your watch? (timezone is nor relevant this step!) Based on his answer time value must probably set by hand/dialog and corrected with date -s "value". d) Next question is: Where do you live, what's your timezone? Based on the answer we should set/export TZ and display the time again with date e) Assumed that last step shows the correct local time for the user (datetime value AND timezone) we should ask: Do you want keep your hardwareclock(BIOS) in localtime or UTC? What we have this moment? A correct system time based on users selections. We have also TIMEZONE var and HARDWARECLOCK for the generated rc.conf later. As a last step we now should set the hwclock/BIOS according to the system time (either as localtime or UTC, based on HARDWARECLOCK). During system config we must also copy the according timezone file to /mnt/etc/localtime early (before any chroot'ing), but we should NOT do this in the live cd system! IMHO this could be the way we should handle time setting things during installer/aif. ========== END QUOTE ======== > During system config we must also copy the according timezone file > to /mnt/etc/localtime early (before any chroot'ing), but we should > NOT do this in the live cd system! Why before any chrooting? what do you mean with "we should NOT do this in the live cd system!" ? I mean, the installer runs in the liveCD, so from the livecd we have to copy /etc/localtime to /mnt/etc/localtime, no? Some thoughts: 2a) If a user would happen to live in the UK (GMT timezone, eg UTC+0) then for him UTC === localtime right? so by "coincidence" he would have the correct time. Is there any functional difference between a hardware clock running "as UTC" or a hardware clock running "in localtime for the UTC/GMT timezone" ? I think not but I'm not sure. Similarly 2b) On the installCD we use UTC by default, so this means the time will _only_ be correct if the users clock is in UTC _and_ he lives in a UTC/GMT timezone, no? I think it would be really interesting to compare your ideas to what tpowa has written: http://projects.archlinux.org/?p=archboot.git;a=blob;f=usr/share/archboot/t… About Gerhard's solution: if the clock is UTC, shouldn't we first ask for the timezone and then ask for the date? because the time we will present in 2b) is probably incorrect if we don't know the timezone yet. Shouldn't we do a->d->b->c->e ? About tpowa's stuff: what's line 47-49 for? in dohwclock, why don't you add --noadjtime ? Note that I have sort of ported tpowa's tz script into aif ( see http://github.com/Dieterbe/aif/commit/5cd407fbb9b44b476ae7c9d460594322f465c… ) but of course it will probably need to change depending on this discussion. Dieter

3 3

[arch-releng] /usr/bin/km, loadkeys and dumpkeys
by Dieter Plaetinck 26 Feb '09

26 Feb '09

While figuring out http://bugs.archlinux.org/task/13374, I was inspecting /usr/bin/km, it does "loadkeys" from the kbd package to load the keyboard table. But unfortunately it looks to me you can't just get the name of that table afterwards (eg with dumpkeys), you can only get the table itself from the kernel. I am correct or am I missing something? How will we fix this, let km export an environment variable which we pull in the installer? Who maintains the "km" tool? it is not included in any package. Dieter

3 4

[arch-releng] size of the "display" (framebuffer?) on our images
by Dieter Plaetinck 20 Feb '09

20 Feb '09

Hi all, I find that the size of our "display" (this is the framebuffer resolution, right?) is quite small. Most distro's that I know of have a bigger size/resolution when booting their isos. Is there a reason we keep it so small? compatibility with older systems? If we could make it a bit bigger, that would be really useful, See for example http://users.edpnet.be/dieter/aif/aif-alpha_0.6-disks-overview-dia.png I just have sometimes many things to show which doesn't fit in the screen anymore :) Dieter

7 11

[arch-releng] Fw: [arch-dev-public] Arch Linux release in the press
by Dieter Plaetinck 19 Feb '09

19 Feb '09

Cool stuff. Aren't we the first distro to officially release images with 2.6.28/ext4 et al ? Dieter Begin forwarded message: Date: Tue, 17 Feb 2009 13:50:44 +0100 From: Andrea Scarpino <andrea(a)archlinux.org> To: Public mailing list for ArchLinux development <arch-dev-public(a)archlinux.org> Subject: Re: [arch-dev-public] Arch Linux release in the press 2009/2/17 Thomas Bächler <thomas(a)archlinux.org>: > I just noticed by accident that our release announcement made it to > heise open. This is the first time that Arch has been mentioned on > heise at all, so I am a bit psyched. Anyway, for those who know > German, read here: > http://www.heise.de/open/Arch-Linux-2009-02--/news/meldung/132693 > > It's not much more than a translation of the release announcement, but > should still attract some more German users. > > I'd like to use this thread to collect more press coverage of our > release, so if you see anything, post it here (or reply on > arch-general). Also a popular Italian site[1] have announced the our ISO is released :) nice [1] http://www.ossblog.it/post/4672/rilasciata-archlinux-20092 -- Andrea `BaSh` Scarpino Arch Linux Developer

8 20

[arch-releng] website improvements
by Dieter Plaetinck 19 Feb '09

19 Feb '09

Hi all, some releng-related ideas for improvements of the website, loosely based on the suggestions from someone on the forums ( http://bbs.archlinux.org/viewtopic.php?pid=497610#p497610 ) @ http://www.archlinux.org/download/ I would create a new section above "Buy a CD" called "Latest release" or something. This section would contain: * the last release version + date of release. * release notes of that specific release. * a tiny note that you don't need to reinstall if you want to upgrade your system. * links to the bugtracker, mailinglist your thoughts?

5 8

[arch-releng] RC2 ISOs and final release
by Aaron Griffin 17 Feb '09

17 Feb '09

The new RC2 ISOs are up. http://dev.archlinux.org/~aaron/archiso/ Roadmap: http://bugs.archlinux.org/roadmap/proj6 Bugs fixed in RC1 and RC2: http://bugs.archlinux.org/task/12896 http://bugs.archlinux.org/task/12949 http://bugs.archlinux.org/task/13068 http://bugs.archlinux.org/task/13070 http://bugs.archlinux.org/task/13140 http://bugs.archlinux.org/task/13101 http://bugs.archlinux.org/task/13102 http://bugs.archlinux.org/task/13057 http://bugs.archlinux.org/task/13038 (I think that's it) Please test the above bugs, and anything else on the bug tracker. This should be pretty much the final ISO, so I'm just looking for some confirmations on the above bugs. Known issues: grub "Release notes" is empty (whoops, blame me!)

12 47