| 01:52.45 | Cody` | Finally getting to grab the iso :) |
| 02:15.45 | *** join/#gnu-kbsd asac_ (n=asac@debian/developer/asac) |
| 04:04.53 | *** join/#gnu-kbsd str3y (n=mary@59.176.27.187) |
| 10:01.51 | *** join/#gnu-kbsd l3m_ (n=l3m@ifidyn215.ifi.unizh.ch) |
| 10:22.16 | nyu | looks like glibc-bsd-devel is lagging ~48h |
| 10:24.18 | nyu | i aunnounced that 6.0's been uploaded to unreleased yesterday, so i guess it'll arrive tomorrow |
| 10:24.32 | nyu | maybe we should move this to lists.d.o ? |
| 10:24.48 | braindmg | nyu: I've lost some of your mails to that list I think |
| 10:28.19 | nyu | which ones? |
| 10:29.04 | nyu | azeem: please disregard what I said about the room. I most likely won't be able to attend |
| 10:29.13 | nyu | I'll be busy that weekend |
| 10:29.15 | azeem | oh, ok :( |
| 10:29.43 | nyu | maybe I can change it at last time, but in principle don't count me on |
| 10:43.38 | aurel32 | azeem: about the room for FOSDEM, are you expecting to have a room soon? |
| 10:44.10 | azeem | I hope so |
| 10:46.00 | azeem | aurel32: you're just staying sat->sun, right? |
| 10:46.59 | aurel32 | azeem: yes |
| 12:16.57 | CIA-12 | 03ps-guest * r1202 10/trunk/glibc-2.3-head/NOTES: * update "make check" status |
| 12:31.21 | tarzeau | aurel32: would you mind having mrtg and webalizer on io? |
| 12:33.43 | aurel32 | tarzeau: yes you can install them |
| 12:39.43 | tarzeau | ok webalizer is installed, no snmpd available for mrtg... |
| 12:42.11 | tarzeau | aurel32: i've turned on hostname lookups for apache |
| 12:42.22 | tarzeau | aurel32: you might want to link to the /webalizer page from the main page |
| 13:09.48 | *** join/#gnu-kbsd jharrisonwk (n=jharriso@a24-244-140-15.maxil.com) |
| 13:41.30 | *** join/#gnu-kbsd ema (n=ema@debian/developer/ema) |
| 14:17.40 | CIA-12 | 03rmh * r1203 10/trunk/kfreebsd-6/debian/patches/002_glibc_dev_isp.diff: Add note with upstream status. |
| 15:44.41 | CIA-12 | 03rmh * r1204 10/trunk/kfreebsd-6/debian/patches/002_glibc_dev_isp.diff: 002_glibc_dev_isp.diff: Remove isp.c part (not really needed). Add note about ispvar.h. |
| 15:45.39 | CIA-12 | 03rmh * r1205 10/trunk/kfreebsd-6/debian/patches/003_glibc_dev_aicasm.diff: 003_glibc_dev_aicasm.diff: Switch to <bsd/queue.h>. |
| 15:46.00 | nyu | I think 003_glibc_dev_aicasm.diff is ready to be sent upstream. Anyone wants to review it? |
| 17:21.04 | *** join/#gnu-kbsd ar2r (i=ar2r@ts5-a186.Spb.dial.rol.ru) |
| 18:01.37 | tarzeau | i can't see no freebsd6 stuff in unreleased |
| 18:02.49 | nyu | tarzeau: http://kfreebsd-gnu.debian.net/debian/pool-kfreebsd-i386/main/k/kfreebsd-6/ |
| 18:03.17 | tarzeau | can i have multiple kernels now? |
| 18:03.25 | tarzeau | i don't have grub here, it's the bsd boot loader |
| 18:08.11 | tarzeau | my machine will reboot if i install that? |
| 18:08.20 | tarzeau | i mean it will boot again? |
| 18:11.00 | *** part/#gnu-kbsd str3y (n=mary@59.176.27.187) |
| 18:11.40 | braindmg | nyu: the bsd/queue.h change is wrong |
| 18:11.50 | braindmg | nyu: you are assuming that glibc == libbsd ... |
| 18:18.22 | nyu | braindmg: how about #ifndef BSD ? |
| 18:18.35 | nyu | btw, I have a patch for mini-dak. would you have a look? :) |
| 18:20.14 | CIA-12 | 03rmh * r1206 10/trunk/web/patches/upstream-only/mini-dak_testing.diff: Add mini-dak patch to generate testing Packages files. |
| 18:21.07 | nyu | I've put it in svn. I could only test the Packages file generation itself, but I've taken care to integrate it well within the mini-dak framework |
| 18:21.54 | nyu | braindmg: or maybe #ifndef __FreeBSD__ |
| 18:23.29 | braindmg | nyu: yes looking (mini-dak) |
| 18:23.38 | braindmg | nyu: well you have to check if libbsd is available |
| 18:23.58 | braindmg | not bsd or not freebsd does not imply libbsd ;) |
| 18:24.06 | nyu | with their build system that can be crazy :) |
| 18:24.33 | nyu | they're not using autoconf precisely |
| 18:25.10 | nyu | well it doesn't matter. it's just one of the patches |
| 18:25.54 | nyu | i'll put it on hold untill we have a clearer idea on how we're going to solve the sys/queue.h issue |
| 18:27.03 | nyu | braindmg: oh, I could not find how to get a path to the local debian/ dir though :) |
| 18:28.34 | nyu | tarzeau: no you can't have multiple kernels yet |
| 18:28.48 | nyu | tarzeau: it'll boot again, but it won't work perfectly |
| 18:28.52 | nyu | PTYs won't work |
| 18:29.48 | nyu | but it works well enough to setup network and apt-get a 5.x kernel ;) |
| 18:30.24 | nyu | bbiaw |
| 18:36.46 | braindmg | hmm there's a script who collects unstable Packages lists already |
| 18:37.26 | braindmg | they are on the cache dir (the uncompressed ones) |
| 18:37.46 | braindmg | the problem with this patch is that it will not work ;) |
| 18:38.10 | braindmg | nyu: mini-dak does not keep state |
| 18:38.24 | braindmg | nyu: and testing needs to be taken into accound when obsoleting |
| 18:38.39 | braindmg | account even |
| 18:38.53 | braindmg | I'd rather go with dak than try to support testing |
| 18:41.46 | tarzeau | haha, i guess i'll keep 5.x |
| 19:16.28 | nyu | braindmg: why doesn't obsoleting take testing into account? |
| 19:16.43 | nyu | in crontab i've set it to generate Packages just before obsoleting |
| 19:17.06 | nyu | you don't need to keep state |
| 19:17.33 | nyu | tarzeau: if you don't plan to debug the problems, 6.x is not worthy yet |
| 19:17.52 | tarzeau | no i'm just a user |
| 19:55.59 | *** join/#gnu-kbsd xsun_ (n=xsun@20150078090.user.veloxzone.com.br) |
| 20:10.50 | braindmg | nyu: yes I have, and that will just create the packages files, and then remove the packages from testing |
| 20:11.04 | braindmg | (it will only work in case the version in unstable and testing is ==) |
| 20:11.20 | braindmg | nyu: because it uses the .changes info to get on which suite it goes |
| 20:11.33 | braindmg | and uploaded packages are either unstable, unreleased, or experimental |
| 20:11.35 | nyu | I'm missing something |
| 20:11.44 | nyu | how does obsoleting work? |
| 20:11.45 | braindmg | testing is just a state in katie db |
| 20:12.27 | nyu | i thought obsoleting didn't have to care about which dist a package belongs to |
| 20:13.12 | braindmg | then how would you do it? ;) |
| 20:13.15 | nyu | this is how i assumed it works: |
| 20:13.47 | nyu | run through the Packages file for each dist (unstable, unreleased and testing) |
| 20:13.58 | nyu | only remove files that aren't referenced in any list |
| 20:14.08 | braindmg | and how do you generate those lists? |
| 20:14.23 | nyu | unstable and unreleased from the .changes files |
| 20:14.38 | nyu | testing from that hack of mine ;) |
| 20:15.36 | braindmg | well packages files are a subproduct |
| 20:15.49 | braindmg | otherwise I'd have to check for each package all Packages files |
| 20:15.56 | braindmg | I have a master changes list file |
| 20:16.04 | nyu | I see |
| 20:16.06 | braindmg | with all packages from each dist |
| 20:16.24 | braindmg | and a package cannot be in more than one |
| 20:16.37 | braindmg | otherwise it has to be removed depending on which ordering |
| 20:16.49 | braindmg | unstable < unreleased < experimental |
| 20:17.00 | nyu | well, with testing present there would be the possibility of a package being more than once |
| 20:17.02 | braindmg | if unstable has a package bigger than unr or exp those get removed |
| 20:17.11 | braindmg | if unr has bigger than exp exp gets removed |
| 20:17.24 | nyu | can't you exclude testing from that part of the process? |
| 20:17.41 | braindmg | testing does not exist =) |
| 20:17.53 | nyu | like, master list file -> generate unstable & unreleased -> obsolete -> testing |
| 20:17.55 | braindmg | the info I'm handling only takes into account real suites from .changes |
| 20:18.55 | braindmg | (I'm eating something oily so may not be able to type for a while, w/o making of my keyboard a mess ;) |
| 20:19.04 | nyu | haha |
| 20:20.36 | nyu | so, how about turning Packages files into something mandatory rather than a subproduct? |
| 20:21.02 | nyu | then make archive-obsolete check these individualy and be able to tell the difference between unstable, unreleased, etc |
| 20:21.23 | nyu | it isn't always a good idea that an unstable upload obsoletes unreleased or vice-versa anyway |
| 20:22.41 | nyu | uhm wait |
| 20:22.53 | nyu | my hack has a dessign problem too |
| 20:23.47 | nyu | when packages disappear from the unstable Packages, they won't be reachable for testing |
| 20:24.02 | nyu | even if archive-obsolete doesn't remove them |
| 20:24.50 | *** join/#gnu-kbsd otavio (n=otavio@debian/developer/otavio) |
| 20:24.52 | nyu | how about making it something external? I could cook up something that builds .changes files for testing |
| 20:25.10 | nyu | only uploading the .changes files should be enough i think |
| 20:25.23 | nyu | but still archive-obsolete would need to check dists separately |
| 20:26.43 | braindmg | * using Packages files, will make mini-dak more complex |
| 20:27.16 | braindmg | * mini-dak assumes there's no .changes file will shared content with other .changes file |
| 20:27.25 | braindmg | why do you think I did the pool splitting? ;) |
| 20:27.46 | nyu | i see.. major redessign involved |
| 20:28.35 | braindmg | well it's called *mini*-dak for a reason |
| 20:28.56 | braindmg | you want dak, and I'm not going to rewrite mini-dak into dak, that'd silly =) |
| 20:29.07 | nyu | heh |
| 20:29.12 | nyu | how about reprepro? :) |
| 20:29.19 | braindmg | nyu: consider mini-dak as a cheap archive soft, which gives most of dak features, being stateless |
| 20:29.35 | braindmg | so I can regenerate the whole archive with just the pakages and .changes files |
| 20:29.47 | braindmg | nyu: why do you need testing so desperately? |
| 20:29.56 | braindmg | I'd just wait to be included in debian |
| 20:30.09 | nyu | that won't give us testing, only unstable |
| 20:30.21 | braindmg | so more in my favour =) |
| 20:30.33 | braindmg | it will be a pain maintaining testing outside |
| 20:30.41 | nyu | uhm true |
| 20:31.00 | braindmg | i'd say, just work on the port so it can have a real testing in debian |
| 20:31.04 | nyu | i'll think how it can be done outside |
| 20:31.08 | braindmg | less work for everyone |
| 20:31.37 | braindmg | nyu: you'll have to handle cases where packages in testing are not in sync with what we have built |
| 20:31.41 | braindmg | and the like |
| 20:31.49 | nyu | i thought about that already |
| 20:31.53 | nyu | it's not a big problem |
| 20:32.01 | braindmg | and do you migrate packages from unreleased to testing? |
| 20:32.05 | nyu | no |
| 20:32.08 | braindmg | i would not do that for example |
| 20:32.18 | nyu | agreed.. it's a bad idea |
| 20:32.23 | braindmg | then testing will not be a complete distro anyway |
| 20:32.31 | nyu | they'd be just added without migration |
| 20:32.48 | nyu | not all of them would be installable, but unreleased is a dirty hack anyway |
| 20:32.53 | braindmg | really I'd spend the time fixing the real issure |
| 20:32.55 | braindmg | issues even |
| 20:33.04 | nyu | uhm there aren't much issues now |
| 20:33.25 | nyu | just get maintainers to apply patches for base |
| 20:33.26 | braindmg | we don't have 100% archive built =) |
| 20:33.36 | braindmg | no reply from adrian yet |
| 20:33.40 | nyu | and wait for ftp-masters to add the port |
| 20:33.49 | nyu | we don't need 100% to get unstable! |
| 20:33.53 | braindmg | I've to resend the patches rediffed against the autoconf version thought |
| 20:33.56 | nyu | not even for testing |
| 20:34.06 | braindmg | nyu: yeah, but it'd be cool to have =P |
| 20:34.28 | nyu | also, the amount of built packages tends to increase when maintainers update libtool and we get more libraries -> more build-deps |
| 20:34.43 | nyu | OTOH, a testing archive would help a lot |
| 20:34.49 | nyu | making the port popular |
| 20:35.26 | braindmg | dunno, I think having it in debian will make it way more popular |
| 20:35.43 | nyu | yes, but we can't speed that up now |
| 20:35.53 | nyu | we met the requirements |
| 20:36.05 | nyu | just need to wait till they add kfreebsd-i386 |
| 20:36.17 | braindmg | no, till the fix the archive |
| 20:36.24 | braindmg | not even amd64 is in :) |
| 20:36.30 | nyu | yeah, whatever |
| 20:36.42 | nyu | need to wait till they do whatever is needed and then add kfreebsd-i386 |
| 20:37.15 | nyu | braindmg: ok you've convinced me that testing can't be inserted in gnuab |
| 20:37.23 | braindmg | I've added ls-lR generation to the thingy (cannot remember if I told) |
| 20:37.25 | nyu | i'll think how it can be done externaly ok? =) |
| 20:37.29 | braindmg | heh |
| 20:39.05 | xsun_ | Debian GNU/NetBSD project is stopped or someone is working on it? |
| 20:39.16 | nyu | xsun_: stopped (both of them) |
| 20:39.28 | nyu | braindmg: btw you can nuke knetbsd-i386 as well |
| 20:39.44 | nyu | i forgot it's not the same pool as netbsd-i386 |
| 20:41.04 | nyu | braindmg: how much does a mirror of kfreebsd-i386 unstable take? |
| 20:41.12 | CIA-12 | 03guillem * r1207 10/trunk/libbsd/ (ChangeLog include/bsd/cdefs.h): Disable __unused, it conflicts with a struct member in a Linux header. |
| 20:41.23 | nyu | argh :) |
| 20:41.31 | nyu | yeah, I remember this |
| 20:41.32 | braindmg | yeah :< |
| 20:41.59 | braindmg | I had patched ufsutils due to that, and cannot remember if me or bal00 reintroduced that in libbsd |
| 20:42.03 | aurel32 | nyu: I am not sure the patch you post for tracking testing will be really useable |
| 20:42.18 | braindmg | aurel32: it's not =) |
| 20:42.20 | nyu | aurel32: the mini-dak one? |
| 20:42.31 | aurel32 | nyu: I mean with some packages being in unreleased, you will need to also track those ones |
| 20:42.32 | nyu | it won't work. braindmg just explained to me :) |
| 20:42.42 | aurel32 | nyu: if not, testing won't be self-contained |
| 20:42.46 | aurel32 | ah ok |
| 20:42.53 | nyu | unreleased is not a problem though |
| 20:43.03 | nyu | it can be added to sources.list along with testing |
| 20:43.04 | braindmg | ^ backlog ;) |
| 20:43.22 | nyu | the problem is in the gnuab side. the client side is safe AFAIK |
| 20:43.29 | xsun_ | I have some doubts about how networking is implemented under kfreebsd. I mean, debian works with /etc/network/interfaces and this is very different of FreeBSD networking isnt? |
| 20:43.37 | nyu | yep |
| 20:43.42 | aurel32 | nyu: doing such will probably make some program uninstallable |
| 20:43.50 | aurel32 | nyu: I am not sure it is gnuab |
| 20:43.51 | braindmg | I may finish libbsd today... |
| 20:43.54 | nyu | xsun_: our ifupdown is adapted to work with FreeBSD ifconfig |
| 20:44.05 | nyu | xsun_: so basicaly you get debian-like network setup |
| 20:44.07 | aurel32 | nyu: until we have all package in unstable (ie no unreleased), it may causes some problems |
| 20:44.21 | xsun_ | nyu: hmm, great |
| 20:44.30 | nyu | aurel32: yes, but unreleased is only for hacks, so I think it's acceptable if some packages can't be installed |
| 20:44.31 | xsun_ | nyu: what about the system init? |
| 20:44.36 | nyu | aurel32: they need to be removed anyway |
| 20:44.39 | braindmg | aurel32: one question about libfreebsd, why are the __foo symbols exported? |
| 20:44.40 | xsun_ | it uses update-rc.d? |
| 20:44.41 | nyu | xsun_: debian |
| 20:44.52 | nyu | xsun_: it's all debian except a few utils like mount or ifconfig |
| 20:45.00 | xsun_ | got it |
| 20:45.56 | nyu | aurel32: theoricaly, if the base packages were all in unstable, you could run a system without unreleased. the only downside being that you can't install some non-essential things because they aren't present |
| 20:46.24 | nyu | OTOH, the packages in base can be updated in a mixed testing-unreleased set. e.g. libc0.1 won't drag anything else |
| 20:47.18 | nyu | and even if one of them couldn't, that just means it'll be on hold, which is almost the same as using a package from unreleased (on hold untill it's rebuilt manualy, or untill it migrates to unstable) |
| 20:47.22 | xsun_ | knetbsd uses glibc like kfreebsd? |
| 20:47.50 | nyu | xsun_: there were two ports based on knetbsd, one with glibc and one without |
| 20:48.21 | nyu | both are dead now. but the glibc-based one can be re-instated easily since most of the work done for gnu/kfreebsd is very similar |
| 20:48.39 | nyu | braindmg: how much does a mirror of kfreebsd-i386 unstable take? |
| 20:48.43 | xsun_ | hmm, interesting |
| 20:49.44 | xsun_ | netbsd porting dead for some specific reason or the developers just hang up of the project? |
| 20:49.55 | nyu | you'd just need to forth-port the sysdeps fixes into our up-to-date sysdeps tree, and figure out what to do with threads |
| 20:50.11 | aurel32 | braindmg: I don't remember, let me have a look |
| 20:50.44 | nyu | xsun_: basicaly, I moved on to work on kfreebsd-i386 which had more people in it already |
| 20:50.51 | braindmg | nyu: I don't know I don't have it split |
| 20:51.11 | nyu | braindmg: ok what about du -hs pool-kfreebsd-i386 ? |
| 20:51.19 | braindmg | that's another thing ;) |
| 20:51.23 | nyu | ok ok |
| 20:51.27 | nyu | but it gives me an idea |
| 20:51.53 | braindmg | 6.8G pool-kfreebsd-i386 |
| 20:52.00 | nyu | xsun_: and since most of the effort is shared, it's just waiting for someone to ressucitate it |
| 20:52.07 | nyu | braindmg: k thanks |
| 20:52.09 | xsun_ | nyu: I see |
| 20:52.25 | nyu | tarzeau, aurel32: do you mind me stuffing ~6.8G into io? |
| 20:52.48 | nyu | only for testing testing purposes |
| 20:52.54 | nyu | (testing testing != testing) |
| 20:52.57 | aurel32 | braindmg: don't know exactly, I think they could be removed |
| 20:53.11 | braindmg | aurel32: just make them static and remove from Versions |
| 20:53.18 | braindmg | (I'd say ;) |
| 20:53.29 | braindmg | aurel32: do you mind if I do? or you do? |
| 20:53.31 | aurel32 | nyu: for my point of view it is not a problem if you don't want to setup a mirror |
| 20:53.41 | aurel32 | braindmg: you can do it |
| 20:53.54 | nyu | aurel32: i'd like to setup a mirror, but only for my own testing purposes |
| 20:53.58 | aurel32 | nyu: but you should ask tarzeau about the network traffic |
| 20:54.12 | nyu | ok |
| 20:54.16 | aurel32 | nyu: I don't understand. What are you trying to do? |
| 20:54.19 | nyu | only incoming traffic will be significant |
| 20:54.41 | nyu | aurel32: create a script that can generate a testing pool from an external host (i.e. gnuab) |
| 20:55.21 | aurel32 | braindmg: note that libfreebsd is now provided by freebsd-lbis |
| 20:55.28 | aurel32 | s/lbis/libs/ |
| 20:55.50 | aurel32 | braindmg: I will remove the old libfreebsd |
| 20:55.56 | nyu | aurel32: when we have that, it'd work equaly on ftp-master and gnuab |
| 20:57.51 | nyu | uhm actualy, i might be able to do it localy |
| 20:58.04 | nyu | let's see if i can grab some disk space ;) |
| 21:00.14 | braindmg | aurel32: oh ok |
| 21:00.20 | aurel32 | braindmg: no I am wrong |
| 21:00.25 | braindmg | aurel32: where's the source for libfreebsd? |
| 21:00.29 | aurel32 | I don't understand anymore |
| 21:00.53 | braindmg | yes freebsd-libs provides the dh files but the source is not there =) |
| 21:00.54 | aurel32 | well ignore what I said I think libfreebsd is the source |
| 21:00.59 | braindmg | ok |
| 21:01.10 | aurel32 | if I remeber I split out libfreebsd from understand anymore |
| 21:01.15 | braindmg | although I'll break the abi ... |
| 21:01.15 | aurel32 | oops |
| 21:01.46 | aurel32 | if I remember I have split out libfreebsd from freebsd-libs because it could be compiled on linux or other arches |
| 21:01.56 | braindmg | (I'd not do that for debian sid thought ;) |
| 21:02.00 | aurel32 | ie it don't need a kernel support |
| 21:02.09 | braindmg | it does not build on linux thought |
| 21:02.24 | braindmg | s/thought/though/ |
| 21:02.54 | braindmg | it has #include <machine/foo.h> stuff for example |
| 21:02.56 | CIA-12 | 03aurel32 * r1208 10/trunk/freebsd-libs/debian/ (libfreebsd-dev.install libfreebsd0.install): Remove libfreebsd0.install libfreebsd-dev.install, this library no has separate source |
| 21:03.49 | aurel32 | yes true |
| 21:04.10 | aurel32 | so maybe we could merge it back to freebsd-libs ? |
| 21:04.12 | CIA-12 | 03guillem * r1209 10/trunk/libfreebsd/libfreebsd-dev.install: Remove crufty file. |
| 21:04.45 | braindmg | aurel32: who's using libfreebsd? |
| 21:06.29 | aurel32 | libkvm |
| 21:07.45 | aurel32 | and also libcam |
| 21:07.53 | aurel32 | but not as a shared object |
| 21:08.33 | nyu | braindmg: it's 4392 MiB |
| 21:08.59 | nyu | debmirror dixit |
| 21:13.31 | CIA-12 | 03aurel32 * r1210 10/trunk/freebsd-libs/debian/ (control rules): |
| 21:13.32 | CIA-12 | Compile fix for libkvm |
| 21:13.32 | CIA-12 | libcam0 don't need to depend on libfreebsd0 |
| 21:25.37 | *** join/#gnu-kbsd jharrisonwk (n=jharriso@a24-244-140-15.maxil.com) |
| 22:48.54 | xsun_ | I see that rc.conf was not excluded from kfreebsd |
| 22:49.19 | xsun_ | Is it rc.conf used actually? |
| 23:17.30 | Cody` | hmm anyone know if it's just more or can the default apache setup not be accessed outside the box? |
| 23:47.42 | Cody` | hmm anyone around? |