[12:25] <Kamion> infinity: l-r-m was breaking d-i, so I've uploaded what I think should be a fix for that
[12:25] <Kamion> hard to test without building new images though
[12:25] <Keybuk> heh
[12:28] <Kamion> Keybuk: line 7 of 10-devfs.rules looks suspicious; missing %?
[12:29] <Keybuk> yup
[12:30] <Kamion> Keybuk: could you replace awk '{print $2}' with sed 's/^[^ ] * //; s/ .*//' in /lib/udev/scsi-devfs please? we don't have awk in d-i
[12:31] <Keybuk> can you mail that one to me?
[10:44] <fabbione> cat /proc/cmdline
[10:44] <fabbione> root=/dev/disk/by-uuid/4d216a51-2317-47a4-872f-125a6d035d08 ro quiet splash
[10:44] <fabbione> it seems to work
[10:45] <fabbione> but there is another side effect we didn't think when writing the specs
[10:45] <fabbione> root is not enough
[10:45] <fabbione> we need to possibly detect other partitions and swap
[10:45] <fabbione> otherwise even if we get root, we might miss the rest of the system
[10:45] <fabbione> that defeats the purpose of the spec
[10:46] <fabbione> bah Keybuck isn't here
[10:49] <infinity> But other partitions should be in /etc/fstab...
[10:49] <infinity> (by uuid, perhaps, but they should be there anyway)
[10:54] <fabbione> the problem is that swap doesn't have a uuid
[10:54] <Kamion> fstab supports the UUID= and LABEL= syntaxes
[10:54] <Kamion> you can use LABEL= for swap
[10:54] <fabbione> and the thing is that yes, the other partitions needs to have uuid too
[10:54] <fabbione> fail to do so, we are in trouble
[10:54] <infinity> But multiple swap partitions can have the same label.
[10:54] <Kamion> mm
[10:54] <fabbione> like a / on ext3 = ok, /home on xfs = nok
[10:55] <infinity> I thought uuid-on-swap was something we were fixing?
[10:55] <fabbione> uuid is a property of the fs
[10:55] <infinity> Yes, and?
[10:55] <fabbione> swap isn't exactly a fs
[10:55] <infinity> mkswap could do uuid magic.
[10:55] <infinity> swap isn't an FS, but it still has magic.
[10:55] <infinity> Not much, but some.
[10:56] <infinity> And losing another few bytes for a UUID isn't the end of the world.
[10:57] <fabbione> no, but you would introduce tons of other problems
[10:57] <fabbione> think of the resume from hibernate that clear the swap or so
[10:57] <fabbione> your approach would assume that swap isn't used by anyone else
[10:57] <fabbione> what if the user dual boot breezy/dapper
[10:58] <fabbione> both clean the swaps in 2 different ways
[10:58] <fabbione> bang
[10:58] <infinity> Yeah, ew.
[10:58] <infinity> Hrmph.
[10:58] <infinity> Of course, if this sort of breakage isn't done some day, it can never be done.  Catch-22.
[10:58] <fabbione> yes i agree
[10:58] <infinity> I'd love SOME way to uniquely identify swa ppartitions.
[10:58] <fabbione> there is :)
[10:59] <fabbione> partition IDs
[10:59] <infinity> Har.
[10:59] <fabbione> but still
[10:59] <fabbione> you don't know if that swap is the one you are allowed to use
[10:59] <fabbione> so it still the suck
[10:59] <fabbione> a possible solution would be to generate a uuid
[11:00] <fabbione> and assign it to the swap as LABEL
[11:00] <fabbione> that might do
[11:00] <infinity> Oh wel, for all the noise people make about the dangers of shared swap, using the wrong swap, etc, etc, it seems to be a reasonably uncommonly-tripped bug.
[11:00] <infinity> People THINK about it far more than they actually get bitten by it.
[11:00] <fabbione> i would rather avoid to be the one crossburned for that
[11:00] <infinity> And yes, we could generate a uuid-like label.  Would be ugly in fdisk output, but that's not the end of the world.
[11:01] <fabbione> i think actually.. that going for LABEL=uuid is a much better approach
[11:01] <fabbione> because it might allow us to do it for all kind of FS
[11:01] <fabbione> since LABEL is at partition level
[11:01] <fabbione> and not FS
[11:02] <infinity> Do we ge LABELs on all partition tables, or just MSDOS?
[11:02] <infinity> I get them on PowerPC.  Yay.
[11:02] <fabbione> no idea
[11:02] <infinity> Well, MacPPC anyway.
[11:02] <fabbione> but i guess we do
[11:03] <fabbione> what fs?
[11:03] <infinity>  /dev/hda7         Apple_UNIX_SVR2 Debian             55398400 @ 2098368  ( 26.4G)  Linux native
[11:03] <infinity>  /dev/hda8         Apple_UNIX_SVR2 swap                1136576 @ 57496768 (555.0M)  Linux swap
[11:03] <infinity> Uhh, ext3, not that that matters.
[11:04] <fabbione> no, it shouldn't
[11:04] <fabbione> that's why i was cross checking ;)
[11:04] <infinity> Not sure if all partition tables have label-like metadata that gets translated, but at least the three release arches would be okay.
[11:05] <infinity> I don't recall if BSD disklabels and slices do it.
[11:05] <fabbione> no idea
[11:06] <infinity> (That was one motivation for UUID, though, is that since it's not at the partition table level, we're not subject to weird architectures and their weird partitioning schemes)
[11:06] <fabbione> that's why we can use uuid over label protocols
[11:07] <fabbione> all of this assuming we can stick such a long label
[11:07] <infinity> Look for uuid, fall back to label, if we have neither, cry?
[11:07] <infinity> No, we can't have labels that long they'd need to be a bit less unique.
[11:07] <infinity> DOS labels are... 12 chars?... 16?... I don't recall..  But short.
[11:08] <fabbione> crap
[11:08] <fabbione> i suggest we postpone the spec for dapper+1
[11:08] <fabbione> this is getting already too hairy
[11:16] <fabbione> hey Keybuk
[11:17] <fabbione> Keybuk: in about 10 minutes you want to check the irc log for this chan (last 30 minutes discussion)
[11:17] <fabbione> about probe for root fs
[11:19] <Keybuk> ok
[11:24] <Kamion> infinity: DOS labels are 11 characters, according to 'head debian-installer/installer/build/config/x86.cfg'
[11:40] <Keybuk> *giggle*
[11:40] <Keybuk> for those following the "Dude?  Where's My DMA?" bug
[11:41] <Keybuk> it cleared itself up for mdz all by itsself
[11:41] <Keybuk> with BenC saying the only change to piix was a tweak to the modular IDE driver patch that couldn't POSSIBLY have caused it
[11:41] <Keybuk> upstream IDE subsystem maintainer has identified the patch causes problems for us
[11:41] <Keybuk> it's the (you guessed it) modular IDE driver patch!
[11:58] <Kamion> Keybuk: let me know whenabouts you're uploading udev with the changes I mentioned on IRC last night; I'll need to rebuild d-i with those to get the live CD working
[11:59] <Keybuk> yup
[11:59] <Keybuk> will be this morning
[11:59] <Keybuk> just ploughing through the things everyone sent me overnight for my attention this morning <g>
[11:59] <Kamion> ta
[12:03] <fabbione> i wonder if we have dpkg-query in d-i somewhere...
[12:08] <Kamion> no
[12:08] <Kamion> no plans to add it either
[12:09] <Kamion> you can look through /var/lib/dpkg/status in d-i, but obviously that will only list udebs
[12:09] <Kamion> if you want to inspect /target, chroot to it
[12:09] <Keybuk> infinity: what's the general stance on useful-things-for-debugging in initramfs
[12:09] <Keybuk> like lsmod, udevmonitor, etc.
[12:09] <fabbione> Kamion: yeah the issue is that we can't trust what's in /target ;)
[12:10] <fabbione> Kamion: that's why i am looking at several different options
[12:10] <Kamion> fabbione: then you can't trust /target/var/lib/dpkg/status either ...
[12:10] <fabbione> Kamion: i know. that's why there will be 2 checks available. one that uses status and one that will gather pkgs info from the files installed on the system
[12:11] <fabbione> but the latter is way slower than the former and prone to more false positives
[12:11] <fabbione> as it stands now i am implementing all small shell functions do to almost atomic operations that requires less tools as possible
[12:12] <fabbione> discarding one in favour of another it's easy
[12:13] <Keybuk> fabbione: you asked me to check the irc log, I assume about the /dev/disk stuff?
[12:16] <fabbione> Keybuk: yes
[12:17] <Keybuk> I'm not sure I understand the problem ... the root filesystem knows where the other partitions are
[12:17] <infinity> Keybuk : I wouldn't be against a DEBUG=yes flag in initramfs.conf that optionally copied in some debug stuff, and could be seen by other hooks (like udevs) to copy debug stuff for them...
[12:18] <fabbione> Keybuk: no it doesn't... it does if the disk doesn't change name..
[12:18] <infinity> Keybuk : Not sure we want debug bloat in all initramfs images, hence the flag springs to mind as sane.
[12:18] <Keybuk> fabbione: the disk is named
[12:18] <Keybuk> it has a serial number
[12:18] <fabbione> Keybuk: but we are using uuid exactly because we want to be able to move it around
[12:18] <Keybuk> you could use /dev/disk/by-id/usb-<MODEL NO>_<SERIAL NO>-part2
[12:18] <Keybuk> (inside the root filesystem)
[12:19] <Keybuk> then use root=/dev/disk/by-uuid or whatever to find the root filesystem itself
[12:19] <fabbione> that won't work either..
[12:19] <Keybuk> why not?
[12:19] <fabbione> 0 lrwxrwxrwx 1 root root   9 2005-12-02 09:41 scsi-0ATA_WDC_WD1200JB-00CLinux_ATA-SCSI_simulator -> ../../sda
[12:19] <fabbione>  <-
[12:19] <fabbione> this is an IDE disk in a USB external box
[12:20] <Keybuk> right?
[12:20] <fabbione> i could remove it from there
[12:20] <fabbione> stick it in my desktop
[12:20] <fabbione> that would change to ATA
[12:20] <fabbione> sorry
[12:20] <fabbione> ata-*
[12:20] <Keybuk> use partition labels then
[12:20] <Keybuk> and /dev/disk/by-label
[12:21] <fabbione> Keybuk: label can only be 11 chars
[12:21] <fabbione> there is a high possibility of clashing
[12:21] <fabbione> the reason why we did chose uuid was exactly because of its meaning
[12:21] <Keybuk> pretty low probabibility
[12:21] <Kamion> what's wrong with using /dev/disk/by-uuid/ for the other filesystems too (apart from swap)?
[12:21] <fabbione> Kamion: not all FS support uuid
[12:21] <Kamion> Keybuk: quite high if you have two parallel installations done with the same installer
[12:21] <Keybuk> most the FS we care about support uuid
[12:21] <Keybuk> for those that don't generate a random label
[12:21] <fabbione> root on ext3 and home on fancy fs
[12:21] <fabbione> you are doomed
[12:22] <Keybuk> that gives you a 1 in 269561249468963094528 chance of clash
[12:22] <Keybuk> we don't support home on "fancy fs"
[12:22] <fabbione> Keybuk: yes we do. we still provide the option for manual partitioning
[12:22] <fabbione> and iirc not all the selectable FS have uuid
[12:22] <Keybuk> so?  just tell them "uh, no, go back and fix this"
[12:23] <Keybuk> or for those FS that don't support uuid, generate a randomly unique LABEL and force it upon them
[12:24] <fabbione> so you would end up with a fstab that will look like: /dev/disk/by-uuid/$longnumber / etc...
[12:24] <fabbione> and other lines with LABEL=
[12:24] <fabbione> that will be quite inconsistent
[12:24] <Keybuk> just use /dev/disk/by-uuid/$uuid and /dev/disk/by-label/$label
[12:24] <Keybuk> that's not inconsistent
[12:24] <fabbione> Keybuk: what happens if 2 lables are clashing?
[12:25] <fabbione> labels even
[12:25] <fabbione> at udev level.. does it go foobar? or it continues like if nothing happen
[12:26] <Keybuk> just makes a link for one of them
[12:26] <Keybuk> and the changes of two labels clashing is incredibly remote
[12:26] <Keybuk> when we have 250 billion billion installations, we can worry
[12:27] <fabbione> with 11 chars is a bit less than that
[12:27] <Keybuk> and that's just assuming we only stick to alphanumerics
[12:27] <Keybuk> no, that's 11 alpanumeric chars
[12:27] <fabbione> right
[12:27] <Keybuk> DOS is 11 8-bit chars, so it's a number so high my computer can't calculate it
[12:28] <Kamion> in reality people do kinda want labels to be human-readable ;)
[12:28] <Kamion> or at least PRINTABLE
[12:28] <Keybuk> indeed
[12:28] <fabbione> i sort of agree with Kamion
[12:28] <Keybuk> that's why I stuck to alphanumerics
[12:29] <Keybuk> hell, if you just limit yourself to upper case and numbers, you're still over a billion billion possible labels
[12:30] <fabbione> i was wondering if the first 11 digit of md5sum something would do
[12:30] <fabbione> like md5sum the output of the / uuid with the date in nanosecond
[12:30] <fabbione> that would probably be almost unique
[12:31] <Keybuk> why not just pack the / uuid with the partition number or date?
[12:31] <Keybuk> the / uuid is 37 hex characters
[12:32] <Keybuk> actually, 33 and 4 -s
[12:32] <fabbione> yeah
[12:32] <Keybuk> you could certainly use much of that
[12:32] <Keybuk> and there are shorter uuid standards too
[12:32] <infinity> Can we convert base16 to base36? :)
[12:32] <fabbione> the md5 was to scramble numbers completely
[12:33] <Keybuk> anyway, this isn't a SKY FALLING problem
[12:33] <fabbione> no
[12:33] <Keybuk> there's plenty of ways to identify the partition we want to put the swap on
[12:34] <fabbione> Keybuk: other than LABEL no...
[12:34] <Keybuk> there are :p
[12:34] <Keybuk> we could even go as far as tricks
[12:35] <Keybuk> we could improve /dev/disk/by-path to create a tree of directories, and then figure out which one the root filesystem is on, then use ../part2 if we REEEEALLLY wanted
[12:35] <Keybuk> but that's a bit silly
[12:35] <Keybuk> actually, we probably wouldn't need to improve it at all
[12:35] <Keybuk> just figure out which /dev/disk/by-path is the root fs
[12:35] <fabbione> the problem isn't root
[12:35] <Keybuk> that assumes you want swap on the same disk, of course
[12:36] <fabbione> we can't assume :(
[12:36] <fabbione> we would be able to do so only in one condition
[12:36] <fabbione> getting Kamion to kill manual partitioning
[12:36] <fabbione> till users are able to do partitions as they like
[12:37] <fabbione> we are kind of doomed
[12:37] <fabbione> OR
[12:37] <fabbione> the possibility is to add all this chunk of code only if they use our recipe's
[12:37] <fabbione> via guided partitioning
[12:38] <Keybuk> or just make the manual partitioning generate the random label for every new partition
[12:38] <Keybuk> then if the user changes it to something more readable, which might clash (like "SWAP") that's their problem
[12:38] <Keybuk> and the bug can be closed with something like
[12:39] <Keybuk> "This appears to be your foot that you shot, with your gun"
[12:39] <fabbione> LOL
[12:39] <fabbione> no really.. we can do it only if they use our Guided stuff
[12:39] <Keybuk> no, really, we can do it in manual
[12:39] <fabbione> we can't ensure that the user doesn't have 2 disks
[12:39] <fabbione> and stick half system on one
[12:39] <fabbione> and swap on the other
[12:39] <Keybuk> we don't need to
[12:40] <fabbione> ok let me eat and think about it
[12:40] <Keybuk> just use by-uuid for everything that has it, and by-label for things that don't
[12:40] <fabbione> otherwise i will soon be grumpy ;)
[01:20] <Kamion> Keybuk: could you put the /dev/discs/ support back into scsi-devfs, please? d-i needs it
[01:21] <Kamion> and the Debian 076 package has it
[01:24] <Keybuk> "back into" ?
[01:24] <Keybuk> is it not there?
[01:24] <Keybuk> I just used the scsi-devfs script from upstream
[01:27] <fabbione> Kamion: the hooks i need for that md5sum stuff are in the rescue-udeb right?
[01:28] <Kamion> Keybuk: it's not there, no
[01:28] <Kamion> fabbione: rescue-mode
[01:28] <fabbione> Kamion: thanks
[01:28] <Kamion> fabbione: see yaboot-installer for (at present) the only example of another udeb using it
[01:28] <Keybuk> meh, I'll have to see what Debian patches they have for that
[01:28] <Keybuk> *mutters and grumbles about the installer using obsolete, unsupported and broken scripts* :p
[01:29] <Kamion> it's gradually getting fixed, but the live CD doesn't have parted_devices so disk-detect falls over
[01:29] <Kamion> I've got a patch heading into parted upstream (I hope) to avoid some more of the problems
[01:30] <Keybuk> *nods*
[01:31] <Keybuk> getting the installer to eventually search /sys for drives and cds would be much sweeter
[01:31] <Kamion> it'll just use parted to walk drives
[01:32] <Kamion> hmm, scsi-devfs.sh seems to be in extra/ and in the .diff.gz; does it come from upstream anyway?
[01:32] <fabbione> Kamion: it looks pretty simple the README looks clueful
[01:32] <fabbione> "and" the README..
[01:32] <Keybuk> it comes from upstream, I guess Marco's copied it and modified it for his own nefarious purposes
[01:32] <Kamion> oh, meh, it's completely different
[01:33] <Kamion> it's been in Debian since 0.019-3; I imagine it predates upstream's
[01:33] <Kamion> fabbione: thanks, I wrote the README ;)
[01:34] <fabbione> Kamion: that might be why i was able to understand it :)
[01:36] <Kamion> I'll just use a non-SATA/SCSI system for testing for now
[03:11] <Keybuk> *giggle* at kay
[03:12] <Keybuk> after spending most of yesterday evening arguing that there was no reason to run udevd in initramfs, but just place as /sbin/hotplug
[03:12] <Keybuk> he's now decided we were right after all
[03:31] <jbailey> Keybuk: ^5!
[04:05] <Keybuk> hmm
[04:05] <Keybuk> it seems the ide subsystem could be going away :)
[04:05] <Kamion> huh?
[04:05] <HiddenWolf> Huh?
[04:05] <Keybuk> libata has got parallel ide support now
[04:05] <Keybuk> and that seems to be strongly favoured to replace much of the ide subsystem
[04:06] <Keybuk> pretty much how sata is handled
[04:06] <HiddenWolf> s/away/replaced
[04:12] <jbailey> Keybuk: I asked about that the other day, and I thought ben said ide-generic would still be needed for a while.
[04:17] <Keybuk> you didn't dig enough <g>
[06:27] <Keybuk> right, I think that's all the pile-o-udev bugs solved
[06:28] <Keybuk> Kamion: what installer issues do you have (currently) ?
[06:32] <Kamion> Keybuk: scsi-devfs lack of /dev/discs, live filesystem isn't building, casper needs to be updated to do something initramfs-ish instead of pivot_root
[06:32] <Kamion> I've been concentrating on the live CD rather than on the install CD so it's entirely possible that there are install CD bugs I don't know about yet
[06:33] <Kamion> I'm rolling new install CDs now and will test them shortly
[06:33] <Keybuk> I'm looking into the devfs thing now, I think I may just drop that stuff in wholesale from Debian
[06:40] <makx>  Keybuk: could you take a look at debian #342057, BusLogic not loaded because !sysfs (seems needed for vmware testing of initramfs-tools).
[06:40] <jbailey> makx: I think we fixed that in the Ubuntu kernel.
[06:41] <makx> jbailey: you added sysfs hooks? :)
[06:41] <jbailey> Ben or Fabio did, I think.
[06:41] <jbailey> I try to stay on this side of userspace. =)
[06:41] <makx> why's that not upstream :-P
[06:42] <jbailey>     - [scsi/BusLogic]  Add MODULE_DEVICE_TABLE
[06:42] <Keybuk> it probably is upstream by now
[06:42] <jbailey>  -- Ben Collins <bcollins@ubuntu.com>  Sat, 12 Nov 2005 23:34:38 -0500
[06:42] <jbailey> From the 12th to now, it's hard to guess.
[06:42] <jbailey> I know there's alot queued to go upstream.
[06:44] <makx> a quick grep in git-commits-head shows it's not yet landed for linus.
[06:45] <makx> jbailey: anyway thanks for the hint, good news. :)
[06:49] <jbailey> makx: Or perhaps check with BenC in #ubuntu-kernel
[06:50] <makx> jbailey: for now i'll include it in d-kernel, but yes.
[07:19] <Keybuk> Kamion: wow, I see what you mean about these scsi-devfs scripts being totally different
[07:19] <Keybuk> they aren't even related
[07:21] <Kamion> right, I don't think they share ancestry
[07:21] <Keybuk> the upstream one looks far more complete
[07:22] <Kamion> it does a lot of stuff I don't care about ;-)
[07:22] <Keybuk> what do you actually care about/
[07:23] <Keybuk> do you need all the /dev/bus/*, /dev/scsi/*, etc.
[07:23] <Keybuk> or do you just want /dev/cdroms and /dev/discs ?
[07:23] <Kamion> /dev/scsi/ is good, I don't especially care about /dev/bus/ personally
[07:23] <Kamion> I don't think I actually NEED /dev/scsi/ though
[07:24] <Keybuk> I'm trying to work out how to make this work
[07:24] <Keybuk> we plug all the disks at once, so get_next_number returns 0 for every single disk
[07:27] <Keybuk> what I'm wondering is ...
[07:27] <Keybuk> if I throw all of this away
[07:27] <Keybuk> and instead replace it with a small "enumerate disc-like objects" helper that just makes /dev/discs and /dev/cdroms
[07:27] <Keybuk> would that be sufficient for the installer?
[07:27] <Keybuk> or does it really need /dev/ide and /dev/scsi ?
[07:30] <Kamion> no, it doesn't need those
[07:30] <Kamion> I use them occasionally but I can easily adjust
[07:30] <Keybuk> so it really just relies on /dev/discs and /dev/cdroms ?
[07:33] <Kamion> yep
[07:34] <Keybuk> how about /dev/floppies?
[07:50] <Kamion> /dev/floppy
[07:50] <Kamion> floppy-retriever looks for /dev/floppy/0
[07:54] <Keybuk> does it matter if there are gaps in the numbering, btw?
[07:54] <Kamion> /dev/floppy/0 has to be thus, for the rest probably not
[07:55] <Keybuk> how about for cdroms and discs?
[07:56] <Kamion> "for the rest probably not"
[07:56] <Keybuk> ah, sorry
[07:58] <dilinger> Kamion: any chance of seeing my parted /sys/block patches making it into parted
[07:58] <dilinger> ?
[07:58] <dilinger> for ubuntu's installer
[07:58] <Kamion> dilinger: have they gone upstream / to Debian?
[07:58] <Kamion> I've got parted back into sync now, would be kind of a shame to branch again
[07:59] <Kamion> I can if need be though, file me a bug
[07:59] <dilinger> Kamion: they have gone upstream; I have no idea debian's status w/ them
[07:59] <Kamion> Debian's tracking upstream pretty closely
[07:59] <dilinger> upstream seems to want me to assign copyright to the FSF, but doesn't seem to be able to put me in contact w/ whomever i need to talk to about that
[07:59] <dilinger> *shrug*
[07:59] <Kamion> file a bug and I can keep an eye on it
[07:59] <Kamion> I've done FSF copyright assignment; you can probably just mail their clerk
[08:00] <dilinger> Kamion: file a bug in which bts?
[08:00] <Kamion> Ubuntu
[08:00] <dilinger> bugzilla?  malone?
[08:01] <Kamion> bugzilla
[08:01] <Kamion> http://www.fsf.org/licensing/assigning.html - the maintainer is supposed to send you the questionnaire though
[08:03] <dilinger> well, it's svenl who's expressed interest in the patch, but i guess he wanted otavio to mail me or something
[08:19] <dilinger> ok, submitted
[08:20] <Kamion> thanks
[08:47] <Keybuk> Kamion: http://people.ubuntu.com/~scott/storage_enum.sh
[08:49] <Kamion> I'll take your word for it on the implementation, but the intent looks plausible
[08:50] <Keybuk> that should actually fix our current problems too, as it should reliably never use the same number twice
[09:33] <Kamion>    * Update installer startup script to use "cp -au" like the init script,
[09:33] <Kamion>      instead of "cp -af".
[09:33] <Kamion> Keybuk: please revert that - busybox cp doesn't have -u
[09:33] <Keybuk> d'oh
[09:33] <Keybuk> tsk
[09:33] <Keybuk> busybox sucks
[09:33] <Keybuk> it has a -f that doesn't behave like the real one
[09:33] <Keybuk> and then doesn't have -u
[09:33] <Kamion> and in any case I'm sure it was the "cannot be opened" trap I hit
[09:40] <Keybuk> reverted that bit