=== happyaro1 is now known as happyaron === maclin1 is now known as maclin [04:28] Hi, I'm trying to use an ancient language in ubuntu but unfortunately it seems the language is not listed in text entry as input language. Do you have any idea about how can I edit a current language and save it as the ancient language that I want ? [04:33] cephalex: "Text Entry" is about keyboard layouts [04:33] yep [04:33] and I dont know how to add a new keyboard layout which is not listed [04:34] right, I was wondering because keyboard layouts aren't (always) linked to languages [04:35] and they are mostly country-specific and not language specific [04:37] so I assume you need a keyboard layout for a new script [04:38] thats true its Manichean script *, the language or script belongs to an old region and also religion which is not existing anymore ( Might have few followers in China). [04:39] I know the data used to create keyboard layouts is in /usr/share/X11/xkb/ and you probably want to search for documentation about XKB [04:40] I see, thanks in advance. I needed a kind of keyword to search about it [04:40] alternatively, you could look into creating an ibus input method [04:40] especially if this language has lots of characters like Chinese has [04:42] seems like there aren't that many [04:42] actually it is not an asian language, its an Indo-European language which was spoken and written in Iran like 1500 years ago, it has only 44 characters [04:49] maybe the people at SIL can also help you; they have experience with making it possible to use "unknown" languages & scripts (although for non-extinct ones) [04:55] where is SIL ? how can I reach them ? [05:00] sil.org [05:01] seems like they use Keyman/KMFL for text entry, which seems to be supported by SCIM/iBus input methods [05:10] cephalex: according to https://github.com/ibus/ibus/wiki there should be a #ibus channel here on Freenode [05:11] Thanks in Advance dear JanC [05:11] they can probably tell you if it makes sense to use that or something else [05:16] also: http://linux.lsdev.sil.org/wiki/index.php?title=Installing_KMFL_on_Ubuntu === Drac0 is now known as Guest12161 [08:06] moin [08:09] hey Laney, happy friday! [08:15] hey seb128 [08:15] same to you! [08:15] how are you? [08:15] good! sunny friday :-) [08:16] just had coffee outside to start the day [08:16] how are you? [08:18] o/ [08:19] it's CLOUDY! [08:21] hey willcooke! did you recover from UOS? ;-) [08:21] *yawn* not quite [08:21] I think I'm going to swap some hours today [08:21] be fresh for next week [08:22] that makes sense [08:22] btw you were right [08:22] I was?? That doesnt sound like me [08:22] update-notifier logic to open update-manager after a week is buggy [08:22] ah [08:22] it never worked correctly [08:22] and is not going to open it anymore in xenial [08:22] hehe "how did this EVER work?!" [08:23] oh, thats bad [08:23] it worked because we were not autoinstalling security updates [08:23] and opening the Ui after 1 day for those [08:23] ahhhh [08:23] now we open on normal updates [08:23] which is 7 days [08:23] which conflicts with logrotate [08:23] the code looks at how old are the logs [08:23] can we make it 6 days instead>? [08:23] and they are rotated weekly [08:23] yes [08:23] or we could make it ignore the logs age [08:24] it has a stored value on when update-manager was last open [08:24] unsure why mvo added the log logique [08:24] oki, sounds like we have options then. Let's see what mvo says and make a call then? [08:24] +1 [08:24] thanks seb128 [08:25] btw it's bug #356152 [08:25] bug 356152 in update-notifier (Ubuntu) "update-manager doesn't show updates, even after 1 week" [High,Confirmed] https://launchpad.net/bugs/356152 [08:25] 6 digits bug! [08:25] ha [08:25] mvo fixed the logrotate case [08:25] logged by silbs [08:25] except he didn't [08:25] he made it ignore empty logs [08:25] so e.g dpkg.log is empty when just rotate [08:26] but dpkg.log.1 ctime is the rotation time [08:26] which means the fix wasn't enough [08:26] but I guess we never really hit the issue because we had frequent security updates and opening daily for those [08:26] so yeah, waiting for mvo [08:26] we could just consider the previous u-m use, or we could look at log but their mtime and not their ctime [08:27] that would fix it, the rotated log wouldn't have the rotation timestamp but the last edit one [08:29] sounds full of edge cases to me :) [08:29] but storing a value somewhere also sucks [08:29] coin toss [08:29] well, we have the value atm [08:29] in gsettings [08:30] ah, kk [08:30] $ gsettings get com.ubuntu.update-manager launch-time [08:30] so if that value doesnt exist or is > 6 days old then run [08:30] ? [08:31] the code just do "if MAX(launch-time, log-date) > current-1week; then start" [08:31] or rather < [08:32] e.g it looks at the most recent event between logs date and previous start and check if that's more than a week old [08:32] which is never because of the logrotate [08:32] I'm going to read the bug I pointed again [08:32] got it, and that would handle a fresh install where nothing had ever been run? [08:32] it has quite some text to read [08:32] yeah, and it goes off in to the weeds with people absuing each other [08:33] I don't fully understand the log logic [08:33] I think it's to not start it if you manually used apt [08:33] which makes sense [08:33] hummmmmmmmm - I /think/ I disagree [08:33] like: [08:33] you don't want to annoy synaptic/command line users prompting them with a graphical tool [08:34] I always use apt to install things, but I usually rely on update notifier [08:34] it's tricky [08:34] you could also dist-upgrade manually every 3 days [08:34] and be annoyed by u-m prompting you [08:35] but it would only prompt if there were actual updates right? So in the case of a frequent updater there might not be updates to install? [08:35] and so they wouldnt get prompted? [08:35] though I guess if you are that kind of users you could change the config or the update-notifier "days before notifying" [08:35] true [08:36] it would prompt for updates yes [08:36] but not with the 7 days delay [08:36] oki, well - anyway, sorry to drag this down to nitty details, we can work it out once we know the logic mvo was implementing [08:36] like you log in, apt index refresh, and you would directly get it opening because you didn't use the UI for more than 7 days [08:37] but yeah, the bug has some arguments around those lines [08:37] "if you install/remove a software it resets the updater delay" [08:37] I think the current behaviour is too smart and that makes it confusing [08:37] we better open it weekly if there is an update [08:38] and if you don't like it just change the config to be like annual or never [08:38] +1 [08:39] k, let's check with mvo when he's around and then go for that if he has no objection [08:39] thanks for pointing the issue out! [08:39] perfect, thanks seb128 [08:39] yw [08:39] now, seb128, how do you feel about looking at a u-s-d patch? [08:39] :) [08:40] willcooke, is that the touchpad timeout hack from the oem team? [08:40] seb128, exactly [08:41] I replied the other day saying that their patch looks like an hack and I don't like it/would prefer if they opened an upstream bug/discussed upstream what a proper solution would be [08:41] does look a bit hacky doesnt it [08:41] but that I wouldn't stop them from landing it if they wanted [08:41] like I can see how the hack is desirable/fix the problem now [08:42] if (!strcmp(priv->main_touchscreen_name, g_strdup (device_info[i].name))) [08:42] makes me sad [08:42] but I would prefer if they were engaged into finding a proper solution as well, which might let us replace the hack later on [08:42] for the record it's https://code.launchpad.net/~hui.wang/unity-settings-daemon/unity-settings-daemon-master-touchscreen-fix/+merge/293704 [08:43] looking at the diff [08:43] there's a darn goto in there [08:43] I think they tried to ping Laney next after I said I was not really wanting to put my name next to the ack on it [08:43] lol, indeed [08:43] + if (rtime++ < RETRY_TIMES) { [08:43] + sleep(1); /* sleep 1 second */ [08:43] + goto retry; [08:43] quality code! [08:44] as if I'm more likely to approve a hack than you :P [08:44] Laney, :-) [08:44] urgh [08:44] Laney, note that I didn't redirect them to you, just saw that you got pinged next [08:44] so it's just going to sit there going round and round until the TS comes back. And if it doesnt it will loop forever? [08:44] yeah [08:45] no [08:45] + if (!strcmp(priv->main_touchscreen_name, g_strdup (device_info[i].name))) { [08:45] it tries twice [08:45] wwwwwwwwwwwhy [08:45] not for ever [08:45] seb128, oh yeah [08:45] it'll stop after RETRY_TIMES [08:45] sleep(1) lol [08:46] "If we let the system call do_touchscreen_mapping() before the reconnectting, the u-s-d will crash." [08:46] says the comment [08:46] which makes me think "right, there is a segfault, let's fix it" [08:46] not "let's have a good sleep and not fix the segfault" [08:47] anyway I don't want to rant, cf what I said earlier, I would prefer them to engage in finding a proper fix [08:48] you should comment on there saying that IMHO [08:48] yeah, doing that now [08:48] new wireless AP just arrived :-D [08:49] maybe i'll be able to work from the garden now [08:51] Laney, which one did you get? Can it run openwrt?! [08:52] I got a ubiquiti thing [10:09] https://cgit.freedesktop.org/libreoffice/core/commit/?id=72e6a1365cb08986b542a5beb797634bca62d85b [10:10] ^^ epic way to close a rant in a commit message with "I hate this crap" [11:03] what even is nagios [11:04] Sweet5hark: looks like someone's having fun [11:06] Laney: ya [11:22] hey all [11:50] ricotz: just copied 5.1.3~rc2 for xenial to the ppas ... [11:51] seb128: ^^ if there is no "arrgh, LIbreOffice killed my kitten" feedback from the PPA, thats the one to SRU when upstream releases final in ~one week. [11:51] Sweet5hark, alright, I should be able get to it at the weekend [11:52] Sweet5hark, please get this pushed to yakkety archive too [11:52] ricotz: no sweat with this, upstream hasnt released yet. === Drac0 is now known as Guest13556 [11:55] Sweet5hark, just saying get these 5.1.x update into yakkety too ;) [11:56] ricotz: not gonna happen -- as usual yakkety will release with 5.2.x -- we wont be wasting ressources on 5.1/yakkety without very very good reasons. [12:03] Sweet5hark, hey, k, let's see next week if it's ready then ;-) [12:03] Sweet5hark, I see, I better not answer on that opinion (while an appropriate 5.2 release is like 2 months away) [12:03] hey andyrock! === alan_g is now known as alan_g|lunch [12:22] hair_length--; [12:27] worked this time? ;-) === JanC is now known as Guest26117 === JanC_ is now known as JanC [12:46] finally! === alan_g|lunch is now known as alan_g [13:11] happyaron, hey, could you have a look to backporting the patch for bug #1574347? [13:12] bug 1574347 in network-manager (Ubuntu) "WiFi network list disappears from network manager applet" [High,Confirmed] https://launchpad.net/bugs/1574347 [13:26] Laney, seb128: i got an email saying that further phasing of gnome-software has been stopped because of possible regressions. does that mean that the package hasn't yet been released to all users? [13:26] attente, correct [13:26] that has link to errors.ubuntu.com issues? [13:27] in which case check those and if they are not regression mention it to bdmurray (I saw that you did that yesterday, is there other ones now?) [13:28] there seems to be an increase in the rate for this particular error [13:28] (according to the email at least. i can't actually tell through e.u.c) [13:29] https://errors.ubuntu.com/problem/dc83afe90b31d0984940db9de2ff06b2c6ee8b78 [13:30] this one seems to have spiked though: https://errors.ubuntu.com/problem/71f9f7b2ce32e9d389723076873adffc52b7e0e2 [13:31] that one doesn't have a working retracing :-/ [13:33] those metrics are often not reliable [13:33] if none of the issues seem like new ones/due to the SRU changes just tell bdmurray to flag is as good [13:33] I don't think they are regression [13:34] the first one looks similar to https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1551834 [13:34] Ubuntu bug 1551834 in gnome-software (Ubuntu) "GNOME Software crashed notifying bad install, app installed fine" [High,Confirmed] [13:34] I doubt it's a regression [13:34] that log journal has [13:34] "mar 01 17:20:30 hostname org.gnome.Software[1010]: (gnome-software:3576): Gs-WARNING **: failed to install filezilla.desktop: Timeout was reached" [13:34] so maybe an issue when a timeout is hit [13:43] yeah... i can't figure out why it's happening. it looks like it's trying to upgrade a NULL app, but i can't imagine how that's possible [13:44] app=0x2000000000 is really disconcerting [13:44] so is plugin=0x0... [13:45] could be memory corruption... [13:45] anyway I don't think those are regressions, we shouldn't block the SRU [13:56] attente, ^ [13:56] attente, speaking about SRU, since that one moved to updates do we have a next one lined up? [13:56] seb128: i'm not sure it's not a regression... it appeared first back in february, then disappeared until the sru which brought it back [13:56] or a least of issues for the next one [14:00] attente, https://errors.ubuntu.com/problem/77807d3502a3e74469d5b5dca0a34e9197c647d6 seems similar? [14:00] i'm a bit hesitant to do another sru... we rebased on top of gnome-software 3.20.2, but the delta between 3.20.1 and 3.20.2 is large and there aren't too many changes we made to it yet [14:00] (since that sru i mean) [14:01] yeah, does look similar [14:01] and that was in the release version [14:05] attente, 3.20.2 ... we are going to want to SRU that though no? [14:06] seb128: i'm not sure... it is a big delta [14:06] just means it needs more testing [14:07] but we need to move forward on g-s in the LTS, stalling is not going to work since there are still stability issues and missing features [14:07] and it's not a key component to the system, if we screw it up systems still boot and can still install updates through update-manager [14:07] though not screwing up would be better :-) [14:07] yes we should update to the new upstream [14:07] we would normally do that [14:08] the fact that we are using snapshot doesn't make a difference to that policy [14:09] the question is whether we want that to be the next SRU? [14:09] rather than what? [14:09] or do we want another round of selected changes [14:09] like important ones that would be safer to get through in a week [14:09] where we think the update might need to sit in proposed longer and need some regression-fix-iterations [14:22] attente: is the app getting disposed or something? [14:23] Laney: i don't think so. the memory in that TransactionData struct seems to be getting wiped away, but i can't imagine how since it's on the stack [14:25] why do you think that? [14:31] ximion, hey, I just read that bug with "no application data found" ... dholbach had a similar issue yesterday, apt-get update was failing on a repo not having a Release file which made the /var/lib/app-info/yaml/ symlinks to not be created [14:31] ximion, just mentioning it in case the bug you try to debug is a similar one [14:32] Laney, attente, did we end up having a bug filed about that btw? still unsure on what component the report should be, apt? g-s? [14:32] seb128: if a repo is added, the symlinks should not be touched... [14:32] for that particular bug, it looks like there might be conflicting metadata somewhere [14:32] ximion, well, the repo was not added, it was probably there before upgrading to xenial [14:32] also dholbach changed mirror [14:33] he had symlinks for the wrong mirror [14:33] they never picked the new source due to the E: [14:33] like /var/lib/app-info/yaml/ had symlinks to archive.de [14:33] but he was on the archive.us now [14:33] so the symlinks were broken [14:34] and apt-get update wouldn't update them [14:34] yep, that's an issue - I discussed that with Laney yesterday [14:34] k [14:34] do you know if there is a bug open about it? [14:34] ideally, the broken repos get fixed, because APT doesn't tell us enough information to reliably update the data [14:34] if not I'm going to ask dholbach to file it ... on which component should it be open? [14:34] this is new too... https://errors.ubuntu.com/problem/111ba23deb7463e9f1203f30099e0c2ca6c2af80? [14:37] seb128: since the original cause is in APT, https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1562733 would be the thing [14:37] Ubuntu bug 1562733 in apt (Ubuntu) "apt signature requierements prevent updates from some repositories" [High,In progress] [14:38] the other package involved, appstream itself, could only work around this [14:38] attente, https://bugzilla.redhat.com/show_bug.cgi?id=1281949 suggests it's not [14:38] bugzilla.redhat.com bug 1281949 in gnome-software "[abrt] gnome-software: gs_plugin_loader_set_network_status(): gnome-software killed by SIGSEGV" [Unspecified,Assigned] [14:39] ximion, thanks [14:42] Is it expected that GTK 3.20 will be added to Yakkety? [14:42] Just trying to figure out what may or may not be need for MATE in Debian and Ubuntu. [14:42] flexiondotorg, see https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1576576 [14:43] Ubuntu bug 1576576 in Mozilla Firefox "Update to 3.20 needs work and coordination" [Medium,Confirmed] [14:43] flexiondotorg, summary "would be nice, but it requires theme updates/rewrite for unity/xfce/..., so depends if we find resources to get that done" [14:43] I wouldn't count on it atm [14:43] but wouldn't rule it out either === dgadomski_ is now known as dgadomski [14:48] I tried 3.20 the other day [14:48] nautilus stopped drawing the background for some reason [14:48] and everything else was broken [14:48] :-( [14:49] will poke at it next week a bit [14:49] Laney, the nautilus bg issue is likely https://git.gnome.org/browse/nautilus/commit/?id=7f0e1b0c6869eb826e6c20d31c81bd917779db8f [14:50] k [14:57] Laney, seb128 Migrating to GTK 3.20 is not trivial. [14:58] flexiondotorg, right, that's what the bug I pointed out is about [14:58] seb128, Yep. [14:58] So Debian has GTK 3.20 and MATE has GTK 3.20 compatible themes. Which took the team several months to migrate to GTK 3.20. [14:59] They should apply this expertise to light-themes [14:59] do you have anyone who worked on that and would be interested in helping other flavors? [14:59] Can I drop the MATE 3.18 themes into Yakkety in such a away the Debian sync won't overwrite them? [15:00] seb128, The MATE team has 2 talented themers. One is a Fedora contributor, so has little interest in work on Debian/Ubuntu. [15:00] But he did help willcooke out a few weeks ago. [15:01] The MATE 3.20 themes are now quite widely used by various Fedora spins because they offer complete GTK 3.20 compatibility. [15:05] Laney, seb128 I'll see what can be done regarding light-themes. [15:05] flexiondotorg, thanks [15:05] that would be very useful [15:06] The Ubuntu MATE themes are (pretty much) identical to Ambiance and Radiance. [15:06] so we can probably take inspiration of what has been done there [15:06] are they different from the mate-themes? [15:06] I'm going to see if I can get Ambiant-MATE and Radiant-MATE update for 3.20. If so, merging those changes to light-themes should be trivial. [15:07] great [15:07] brb, restarting to test n-m update [15:07] Yes, mate-themes are the themes for MATE and are distro agnostic. [15:08] We maintain several versions for GTK 3.14, 3.16, 3.18 and 3.20. Because distros move at different paces. [15:09] pitti, I'm noticing that my NFS mounts are not mounting at boot in 16.04. Do you think this might be a systemd issue, and if so, any pointers as to where I can start looking to find out what's going on? [15:09] turnout: 21.4% (+5.0) [15:09] also sudo mount -a doesn't work, but sudo mount ~/Videos (for eg.) does work [15:10] Laney, oof. Still twice what we had here (but that was PCC only) [15:13] Trevinho, andyrock, buon pomeriggio! is there any unity SRU planned? seems like there is a good batch of fixes from andyrock which got a +1 and would be nice to land those [15:14] seb128: Trevinho is in charge of that [15:14] :D [15:14] right [15:31] seb128: yeah, I want to prepare one ASAP... I wanted to land the terminal fix as well [15:32] I've been doing some tests, as the one I have would be quick and fast, but the proper one would need an API break in compiz, so still trying to avoid it [15:32] Trevinho, k, there might be enough to do one without that if it's tricky/going to take longer ... but your call [15:32] Trevinho, what about the bamf/menus issue? [15:32] Trevinho, is the missing menus issue any closer to being solved? I think we should hold on until that's fixed [15:32] Trevinho, did you get a fix? or just a workaround? [15:32] seb128: well, that's actually done right now... But I've just to figure out if the one line change is fine or... [15:32] k [15:33] willcooke: it seems that the bamf fix is enough for many reporters [15:33] willcooke: so, I'll land that anyway... Then we can see if we get more reports [15:34] as the racey nature of the bug, causes that even debugging data could cause false-negatives in tests [15:37] thx [15:41] Laney: if you are bored, could you maybe take a look at why org.kde.kate.desktop is missing from the dep11-generator output? [15:41] see https://github.com/ximion/appstream/issues/39 [15:42] I don't have an easy way to do that atm [15:42] at the curent point in time, I also wonder whether it would be possible to change the existing AppStream metadata files in Xenial, rather than xenial-updates post-release. That would be pretty useful for switching to the appstream-generator too [15:42] and no I'm not bored [15:42] and no it is not [15:42] we absolutely cannot re-publish a released suite [15:42] not even exchanging some files on the server? [15:43] no [15:43] that changes the hashes which is a republish [15:43] well, then this might become a bigger issue than I thought [15:44] or maybe not... - since appstream-generator publishes its media files in a directory layout without main/contrib/non-free, keeping the old files might work easily [15:44] so the old data can be kept in xenial without breaking things, while still switching to the new generator [15:45] yes we'll need a way to import and freeze so things referenced in a frozen suite can never be deleted [15:45] or - even easier - one could define a new media directory :P [15:45] that's what we talked about the other day [15:47] protecting package-ids could work... but every bit in asgen would need to check for the list-of-locked-stuff before attempting to delete things [15:48] do you have a database layer to do it at? [15:49] I'll resurrect my local mirror next week hopefully and run kate on that to see what happened there [16:01] k, calling it a week [16:01] have a nice w.e everyone! [16:03] bye seb128! [16:07] Laney, seb128 It will take some weeks but we gonna have a go at 3.20 support. [16:09] nice! [16:14] pitti: any idea if I can make a conditional (ConditionPathExists=/dev/disk/by-uuid/...) .mount unit mount the thing when the path starts to exist? [16:14] it's for hot-plugging a USB drive and getting it mounted in the right place under /srv [16:18] huh actually this doesn't work even at boot time [16:27] maybe BindsTo= and After= the ....device [16:29] BindsTo is too strong [16:36] Laney: I think adding a final-publish command to asgen which exports all media associated with a specific suite into one directory makes the most sense [16:37] together with marking the frozen suite as untouchable, so the HTML pages and hints don't get updated anymore [16:37] ximion: don't understand [16:38] Laney: before the suite is frozen, you run final-publish on it, copying all media to a new directory dedicated to that suite, and rewriting the MediaBaseUrl to point to that new directory [16:38] then, the generator won't have access to that dir anymore [16:39] what is 'before'? [16:39] that sounds weird [16:39] you have to have someone sitting around babysitting the generator [16:39] at release time [16:39] then publish the suite one more time for that [16:39] jap [16:39] I don't like it [16:39] plus you waste space unless it's made up of hardlinks [16:40] another option would be to split the media directory, but we get huge problems then with deleting old data [16:40] yes, hardlinks would be the thing [16:41] btw, as long as the packages don't get deleted from Xenial, asgen won't touch the xenial suite [16:41] so you already have that guarantee [16:42] if you don't trust the generator on that, I think there is no other way than to move files out of the generator's control [16:43] I trust the generator, but I don't trust myself to not accidentally damage it [16:43] AND the other thing you could gain, as we said the other day, is the ability to reprocess the same thing in another suite [16:44] dep11-generator forget org.kde.kate.desktop -> do the right thing if xenial is frozen [16:45] while I agree that this would be nice, implementing it would be painful - at time, we have a mapping of package -> multiple components, when adding a suite, we would need to reprocess every package again as soon as the suite changes, which is wasteful, or would need to add some additional complexity by adding an optional suite parameter [16:46] * Laney shrugs [16:46] if you accidentially delete a package, it shoould simply return with the new processing step [16:46] s/step/run/ [16:46] if you want to do no work then just ignore the problem and tell people to avoid touching the frozen suite ever [16:47] exception is screenshots, which might become unavailable [16:47] yeah, that's what I do at time ;-) [16:47] (and what I plan to do for Debian) [16:48] annoying isn't it [16:48] what happens if you enable fonts? [16:48] unless, of course, there is some solution which solves this issue [16:48] then you skew the frozen version [16:49] then fonts will show up in all suites which have packages providing them [16:49] even Xenial, but that won't matter, since the xenial suite is frozen on the server [16:49] so, while the appstream server knows more things then, the xenial users won't see them [16:51] not ideal, I agree [16:51] dropping xenial from the config would mean that all packages and components vanish from the database and media cache [16:52] database isn't an issue, media-cache is, that's why I suggested exporting it [16:52] in theory, we could even do that transparently for every suite until is is marked frozen... [16:53] hmm, that could actually work quite well, at the expense of some inode and creating quite some amount of hardlinks [16:54] I'll think about this more [16:57] Laney: making the generator maintain multiple media pools which derive from one "base-pool" might actually be an easy way out [16:57] that way, as soon as a suite is marked as untouchable, its current state is frozen [16:57] sounds heavy on inodes [16:57] but other than that it probably is okay [16:57] means someone needs to do this post-release, but that's something I consider doable [16:58] you could skip loading Packages files for those suites entirely then [16:58] which probably saves some time [16:58] Laney: did you know that dak internally mirrors the whole Debian archive using hardlinks? ^^ [16:58] jup [16:58] it saves time, *and* it makes the DB smaller, as we can drop those packages from the db [16:59] means resurecting an untouchable suite is not a great idea, but that won't happen anyway ^^ [16:59] probably call it released rather than frozen [16:59] frozen already means something else [17:00] or immutable or something [17:01]