February 4, 2017 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | >
February 4, 2017 [00:18:59] *** asmeurer <asmeurer!~asmeurer@71.68.151.43> has joined #fink[00:35:48] *** asmeurer <asmeurer!~asmeurer@71.68.151.43> has quit IRC (Quit: asmeurer)[01:14:23] *** amacks <amacks!~amacks@209-6-115-18.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com> has quit IRC (Quit: Leaving.)[01:14:47] *** mischi <mischi!~michael@185.98.49.17> has quit IRC (Quit: mischi)[01:25:12] *** akh <akh!~akhansen@rrcs-108-178-147-42.west.biz.rr.com> has quit IRC (Quit: akh)[01:45:01] *** juliank <juliank!~juliank@ubuntu/member/juliank> has quit IRC (Quit: Skynet node rebooting.)[02:35:02] *** asmeurer <asmeurer!~asmeurer@71.68.151.43> has joined #fink[02:46:33] *** asmeurer <asmeurer!~asmeurer@71.68.151.43> has quit IRC (Quit: asmeurer)[02:48:09] *** asmeurer <asmeurer!~asmeurer@71.68.151.43> has joined #fink[02:49:37] *** amacks <amacks!~amacks@209-6-115-18.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com> has joined #fink[03:46:19] *** asmeurer <asmeurer!~asmeurer@71.68.151.43> has quit IRC (Quit: asmeurer)[03:54:54] *** asmeurer <asmeurer!~asmeurer@71.68.151.43> has joined #fink[04:05:40] *** OERIAS <OERIAS!~OERIAS@47.137.238.95> has joined #fink[04:15:22] *** asmeurer <asmeurer!~asmeurer@71.68.151.43> has quit IRC (Quit: asmeurer)[04:16:01] *** asmeurer <asmeurer!~asmeurer@71.68.151.43> has joined #fink[04:19:36] *** OERIAS <OERIAS!~OERIAS@47.137.238.95> has quit IRC (Quit: Fuck you all! I am grabbing something to eat!!!!!)[04:26:22] *** asmeurer <asmeurer!~asmeurer@71.68.151.43> has quit IRC (Quit: asmeurer)[04:43:09] *** asmeurer <asmeurer!~asmeurer@71.68.151.43> has joined #fink[05:36:32] *** bn_ <bn_!~bn_@c-65-50-70-13.hs.gigamonster.net> has joined #fink[05:48:31] <bn_> howdy! I recently did a bunch of source installs and noticed my HD space is getting kind of low, are all builds done under /var/.. ?[06:02:12] <bn_> oops, fink v0.34.9 BTW[06:08:40] *** OERIAS <OERIAS!~OERIAS@47.137.238.95> has joined #fink[08:13:00] *** amacks <amacks!~amacks@209-6-115-18.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com> has quit IRC (Quit: Leaving.)[08:53:40] *** asmeurer <asmeurer!~asmeurer@71.68.151.43> has quit IRC (Quit: asmeurer)[09:56:19] *** FinkVC <FinkVC!~irker@snitch.finkproject.org> has joined #fink[09:56:19] <FinkVC> fingolfin: dists/10.9-libcxx/stable/main/finkinfo/utils sed.info[09:56:19] <FinkVC> new upstream version[10:09:28] *** OERIAS <OERIAS!~OERIAS@47.137.238.95> has quit IRC (Ping timeout: 240 seconds)[10:45:37] *** asmeurer <asmeurer!~asmeurer@71.68.151.43> has joined #fink[10:50:01] *** mischi <mischi!~michael@185.98.49.17> has joined #fink[11:11:56] *** asmeurer <asmeurer!~asmeurer@71.68.151.43> has quit IRC (Quit: asmeurer)[12:56:19] *** FinkVC <FinkVC!~irker@snitch.finkproject.org> has quit IRC (Quit: transmission timeout)[13:45:07] *** juliank <juliank!~juliank@ubuntu/member/juliank> has joined #fink[14:06:13] *** mischi <mischi!~michael@185.98.49.17> has quit IRC (Quit: mischi)[15:19:29] *** schwehr <schwehr!~schwehr@c-24-4-248-21.hsd1.ca.comcast.net> has joined #fink[15:50:11] *** mischi <mischi!~michael@185.98.49.17> has joined #fink[16:08:32] *** schwehr <schwehr!~schwehr@c-24-4-248-21.hsd1.ca.comcast.net> has quit IRC (Quit: schwehr)[17:51:09] *** Caelum <Caelum!rkitover@cachemiss.com> has left #fink ("WeeChat 1.6")[18:11:16] *** Snaggle <Snaggle!~Snaggle@47.187.121.248> has joined #fink[18:12:27] <Snaggle> bn_: Fink’s builds are done in /sw/src/build.build by default. /sw/src has the downloaded source code. You can clear anything from either directory with no ill effect towards a Fink install[18:13:43] <Snaggle> Also, the command ‘fink cleanup —all’ will get rid of any obsolete source files and .deb archives that have been superseded by newer versions.[18:16:07] *** Snaggle is now known as SnaggleAway[18:41:31] *** juliank <juliank!~juliank@ubuntu/member/juliank> has quit IRC (Remote host closed the connection)[18:45:23] *** juliank <juliank!~juliank@ubuntu/member/juliank> has joined #fink[19:00:25] *** asmeurer <asmeurer!~asmeurer@71.68.151.43> has joined #fink[19:00:29] <bn_> SnaggleAway: thanks, but I don't see a /sw/src/build.build? Do those get automatically cleaned after builds? I tried doing a "fink cleanup -d" to see what it wold potentially delete, I know it outputs a list of files, but is there an easy way to get a size estimate besides pasting that into a file to run a script over?[19:07:23] <bn_> also, what does "obsolete" mean to fink? I ask because I'm on an older version of fink (v0.34.9) that's on an older platform (10.5.X), so the source tree that I normally check against are already marked EOL-ed, so would doing a cleanup effectively purge all the source tarballs I've cached? (which would seem non-desirable)[19:08:22] *** schwehr <schwehr!~schwehr@c-24-4-248-21.hsd1.ca.comcast.net> has joined #fink[19:09:59] *** asmeurer <asmeurer!~asmeurer@71.68.151.43> has quit IRC (Quit: asmeurer)[19:17:54] *** schwehr <schwehr!~schwehr@c-24-4-248-21.hsd1.ca.comcast.net> has quit IRC (Quit: schwehr)[19:28:45] *** schwehr <schwehr!~schwehr@c-24-4-248-21.hsd1.ca.comcast.net> has joined #fink[19:34:35] <bn_> Is there an easy way to list installed reverse dependencies of a package? I know there's "fink -m list --format=dotty-build | grep ' "name-of-target-package"'" but that seems to output all dependencies for a package, installed or not.[19:36:37] <bn_> I'm trying to figure out what pulled down tetex-texmf-* and whether it's safe to delete the tar.gz-s for that, even though it wasn't listed in the output of "fink cleanup -d"[19:37:09] <bn_> (I don't think I've even used teTeX?)[19:56:21] *** schwehr <schwehr!~schwehr@c-24-4-248-21.hsd1.ca.comcast.net> has quit IRC (Quit: schwehr)[20:06:15] <guillem> saurik: BTW what's your approach for automatic inference of shared library dependencies? I assume you are probably currently using otool directly like fink?[20:10:32] *** schwehr <schwehr!~schwehr@c-24-4-248-21.hsd1.ca.comcast.net> has joined #fink[20:11:50] <saurik> guillem: so my vague understanding is that the goal of that is "build it using a rather full sysroot, and then after the build figure out what other packages it depends on"? I consider that approach flawed as it isn't reproducable: different build orders will result in different configuration results leading to different binaries leading to different dependencies (and different functionality)[20:12:42] <saurik> guillem: in telesphoreo I require dependencies to be manually specified and then I build the package with *only* those other packages available: absolutely no other libraries are going to accidentally get randomly linked into the resulting binaries. (and since telesphoreo is cross-compile only, from linux to ios, nothing from my base system is going to accidentally cause a confusion either)[20:13:09] <guillem> saurik: nope, this is something else, it might well not apply to cydia though[20:14:01] <guillem> in Debian you specify the build-depends in the debian/control file, then specify what to link with in upstream build system maybe restricted via configure or similar[20:14:55] <guillem> and then because in Debian the development packages are split from the run-time shlib packages, and do change based on the SONAME, we use dpkg-shlibdeps, which checks the already built binary to get the list of packages that provide the linked-with libraries[20:15:30] <guillem> if your build and run-time deps are exactly the same then you don't have this "issue" I guess[20:15:40] <saurik> to verify, if the package's configure script happens to check for libpng and finds it on your system and then links against it, what happens?[20:16:00] <saurik> (and to be clear: libpng not being something in build-depends)[20:16:48] <guillem> saurik: that depends on the upstream and how its configure is being called by debian/rules, and it's not really related to the aofrementioned question :)[20:17:06] <guillem> well it is related I guess[20:17:27] <saurik> in telesphoreo I can answer that question: libpng will not be found by configure, as it isn't in build-depends[20:17:52] <guillem> so if that package is present and the binary is linked against it then the resulting object will require it so dpkg-shlibdeps will emit a run-time dependency on the relevant shlib package[20:18:09] <saurik> to me that is a build system flaw[20:18:13] <guillem> saurik: in Debian that is guarantee by building on clean chroots[20:18:55] <guillem> saurik: well if you end up with a binary linking against something then that something does need to be installed or the program will fail to load[20:18:57] <saurik> to me the problem you seem to be more directly looking at is caused by intermingling libraries into build-depends[20:19:23] <saurik> there are packages that are needed to compile the program, like bison[20:19:31] <saurik> and packages that are needed to link the program, like libpng[20:19:36] <saurik> bison should not be in the sysroot[20:19:40] <saurik> libpng should be in the sysroot[20:20:48] <guillem> saurik: this is not so simple, but it is still a bit tangential[20:20:51] <saurik> given the set of runtime link packages you can extrapolate the set of build time development packages if you so desire[20:21:07] <guillem> I assume that if you end up with those packages in the sysroot then things might overlink, in the same way it might happen in Debian[20:21:22] <saurik> fwiw, if you want to school me with an example where this doesn't work, I'm all ears, but it isn't like I'm a newbie at this[20:21:34] <guillem> in addition the correct fix in Debian is to make things resistant against those cases (which are generally considered bugs) either via Build-Conflicts[20:21:46] <guillem> or by passing stuff like --without-libfoo[20:22:35] <saurik> I fundamentally don't trust upstream's configure script to not end up accidentally pulling in dependencies. particular as many packages don't use autoconf or handwrite really broken autoconf[20:22:51] <guillem> saurik: for example with the introduction of multiarch and native cross-building on a non-sysroot layout we have needed to mark dependencies as either linkable or runable[20:23:09] <guillem> and there are the third kind which are linkable and runable which pose problems[20:23:24] <guillem> or runable ones which expose arch specific bits, such as GNU make[20:23:29] <saurik> but why is that an argument for mixing libraries and tools into the same build-depends[20:23:37] <saurik> to me libraries and tools are extremely different[20:23:46] <saurik> and you solve a lot of problems by separating them[20:23:57] <guillem> with its implicit ar handling and similar[20:24:36] <guillem> saurik: if the configure script cannot be trusted there's were we use Build-Conflicts[20:25:07] <guillem> we do not use sysroots, because we have considered them a real PITA and requires path mangling or similar techniques which are really annoying[20:25:16] <guillem> (I consider usage of sysroot fundamentally flawed :)[20:25:47] <guillem> saurik: in any case I take that Cydia does not have a distinction between build and run-time deps? or[20:26:08] <saurik> fwiw, when I said "sysroot", I actually meant the concept of a development and linking environment[20:26:24] <saurik> I think you are thinking of something much more narrow than I do: extracting the packages into a path[20:26:26] <guillem> I see that fink for example uses otool to do the inference in perlmod/Fink/Validation.pm[20:27:00] <guillem> saurik: with sysroot I consider what toolchains use[20:27:20] <guillem> but for a binary distribution that means either building things twice, once for sysroot paths, or using package stuff and mangling them[20:27:25] <saurik> what telesphoreo does is use environment variables to configure the compiler to cobble together a virtual sysroot[20:27:27] <guillem> both problematic[20:30:19] <saurik> "there's were we use Build-Conflicts" <- this would require knowing what is wrong with the configure script[20:31:19] <saurik> you said earlier debian uses chroot. I had never seen it do that, but if it is in fact doing that, shouldn't that obviate the entire concept of build-conflicts? no package outside of build-depends would be in the chroot[20:31:51] <guillem> indeed, but those are usually only done for user's benefit[20:32:23] <guillem> so all build daemons use pristine very minimal chroots containing only build-essential which is the set of implicit build-depends[20:32:31] <guillem> anything else is installed per build[20:32:56] <saurik> to give an example of the kind of perfectionist goal I have: every time I run ./make.sh to build a package in telesphoreo, it should be bit for bit identical to the previous time I ran ./make.sh. I have modified the compiler and the linker and built binary editing tools to fix up some results to make certain this is possible[20:33:10] <guillem> saurik: in any case I was just wondering given that dpkg-shlibdeps does not currently support Mach-O, and whether you had code around doing something similar which could be used to add that support[20:33:38] <guillem> as it appears that given the way you package upstream stuff you do not encounter this problem it's all good :)[20:34:16] <guillem> saurik: in Debian we are getting there too: https://reproducible.alioth.debian.org/[20:34:28] <guillem> many packages should be reproducile right now as well[20:34:41] <guillem> anyway, dinner time for me brb![20:39:00] <saurik> guillem: function dep { otool -lah "$1" | tr $'\n' $'\1' | sed -e 's/\x01 *cmd LC_LOAD_DYLIB\x01[^\x01]*\x01 *name /\x01\x02/g' | tr $'\1' $'\n' | sed -e '/^\x02/!d; s/^\x02//;s/ (offset [0-9]*)$//'; }[20:39:14] <saurik> guillem: $ dep /bin/ls[20:39:14] <saurik> /usr/lib/libutil.dylib[20:39:14] <saurik> /usr/lib/libncurses.5.4.dylib[20:39:14] <saurik> /usr/lib/libSystem.B.dylib[20:42:02] <saurik> guillem: actually, I think I prefer this: function dep { otool -lah "$1" | tr $'\n' $'\1' | sed -e 's/\x01 *cmd LC_LOAD_DYLIB\x01 *cmdsize [^\x01]*\x01 *name /\x01\x02/g' | tr $'\1' $'\n' | sed -e '/^\x02/!d; s/^\x02//;s/ (offset [0-9]*)$//'; }[20:43:09] <saurik> omg, actually, I'm dumb[20:44:30] <saurik> guillem: function dep { otool -L "$1" | tail -n+2 | sed -e 's/^\t//;s/ ([^()]*)$//'; }[20:51:45] <saurik> guillem: ok, looking at dpkg-shlibdeps it seems like you need the rpath in addition to the direct linked libraries. that will require the more complicated parsing[20:51:55] <saurik> guillem: function rpath { otool -l "$1" | tr $'\n' $'\1' | sed -e 's/\x01 *cmd LC_RPATH\x01 *cmdsize [^\x01]*\x01 *path /\x01\x02/g' | tr $'\1' $'\n' | sed -e '/^\x02/!d; s/^\x02//;s/ (offset [0-9]*)$//'; }[20:51:59] <saurik> guillem: $ rpath /Applications/Xcode-8.1.0.app/Contents/MacOS/Xcode[20:51:59] <saurik> @executable_path/../Frameworks[20:51:59] <saurik> @executable_path/../SharedFrameworks[20:51:59] <saurik> @executable_path/../PlugIns[20:52:34] <saurik> guillem: (the mistake I made in the first attempt at dep is I failed to realize there was a -L which just did essentially exactly what was needed)[20:53:05] <saurik> guillem: @rpath expands to any rpath path and @executable_path expands to the location of the binary (the former of course only makes sense in a list of linked libraries, while the latter applies to rpaths as well)[21:03:25] <bn_> I'm not an expert with either build system but assuming nothing underlying or upstream has changed, and excluding any timestamp-related differences, I'd expect any sane build system to generate identical packages or binaries each time it is run with the same compiler and linker flags. Is this not always the case?[21:07:52] <saurik> bn_: to start with, some of the complexity is in fact dealing with "timestamp-related differences" and random numbers and the such. but barring that, we then ask the question "who calculates the compiler and linker flags", and the answer is "some usually overly brittle shell script that is packaged with the source code which may or may not be based on something sane like autoconf and even if it is probably uses autoconf incorrectly in various places"[21:10:42] <saurik> bn_: so it then becomes the job of the high-level distribution build system to essentially isolate things from the system from the package. if you compile wget on three computers, one of which has openssl installed, one which has gnutls installed, and one which has neither installed, you get three different results. if you add openssl to the build-depends, you drop down to two results, as maybe openssl takes precendence if it is installed. so I guess you wh[21:10:56] <saurik> bn_: that was almost certainly cut off for being too long of an IRC line: installed. so I guess you whack-a-mole by adding openssl to the build-conflicts[21:11:11] <saurik> bn_: you can use configure to carefully detail what you want, saying --with-ssl=gnutls[21:11:36] *** schwehr <schwehr!~schwehr@c-24-4-248-21.hsd1.ca.comcast.net> has quit IRC (Quit: schwehr)[21:11:57] <saurik> bn_: but then often the configure script is broken or doesn't even provide a --with-ssl that lets you choose the exact library you want[21:13:42] <saurik> bn_: one option is to compile everything in a chroot, to make sure that only the packages that are actually specified as dependencies are available. another option is to isolate all the parts and make certain that at no time is anything useful on a real path. either way: tons of build systems just assume "I can run configure and build this"[21:31:41] <dmacks_> One of fink's build tools scans for header dependencies. At the time I wrote it, I looked at having it throw an error if the list didn't match the BuildDepends that the maintainer specified. But there wound up being a bunch of corner cases, and also that it threw errors on users that were actually maintainer mistakes that had no impact on the users. Our base isn't so technical, so that seemed like a poor[21:31:45] <bn_> yeah, the few times I've had to interact with the underlying configure or make system has not been very simple.[21:31:47] <dmacks_> tradeoff.[21:31:59] <dmacks_> Instead, it emits the list of packages, but doesn't check against the BuildDepedns list itself.[21:32:41] <dmacks_> So it's a useful maintainer tool and can help diagnose user problems.[21:34:20] *** schwehr <schwehr!~schwehr@c-24-4-248-21.hsd1.ca.comcast.net> has joined #fink[21:37:28] <bn_> hey dmacks_ :) was that in response to my question earlier? or the current discussion about build systems?[21:37:57] <dmacks_> Sorta both...the theme was finding what is used and making sure other things aren't found accidentally.[21:46:39] <bn_> ah, ok. so it sounds like there's currently no real way to list installed reverse dependencies of a package? I can't just grep the meta data files via "fink dumpinfo" for that dependency being listed? I feel like I've asked this question before but I couldn't find an answer in my chat logs so apologies if I've asked this before.[21:54:30] <dmacks_> "reverse dependencies" meaning runtime (not buildtime)? "of a package" meaning one that is currently installed?[21:55:14] <dmacks_> Something like 'dpkg --dry-run r FOO'?[21:57:55] <saurik> I like that suggestion more than what I came up with, but maybe it will serve a purpose ;P function rdepends { apt-cache dump | tr $'\n' $'\1' | sed -e 's/\x01Package:/\nPackage:/g;s/\x01$/\n/;s///' | grep -F $'\x01 Depends: '"$1 " | grep -F $'\x01 Version: ' | sed -e 's/^Package: \([^\x01]*\).*/\1/'; }[22:01:11] <dmacks_> The fink world doesn't make consistent use of apt, so I never think to use it as a source of data. But I agree that when the data is actually at the level of dpkg's databases, apt is often a nicer interface to it.[22:07:03] <saurik> guillem: http://test.saurik.com/guillem/shlibs-1.pl <- I don't actually know perl, but I teach a college-level programming languages course so I pretended I did and wrote this for you.[22:12:55] <guillem> saurik: also just to wrap up the previous talk about needing this at all, I guess the fundamental difference is (probably philosophical) in the level of splitting of upstream packages, if you have a 1:1 source to binary then the deps are trivial to represent, but if you are doing more fine grained splitting then you need something like dpkg-shlibdeps to not add useless run-time deps on the binaries[22:14:29] <guillem> saurik: and thanks for the code, I'll take a look at that and what fink is already doing![22:15:05] <guillem> I will still need to remove many ELF assumptions from the dpkg perl code, so that will be the first step, but ideally dpkg-shlibdeps should eventually support Mach-O natively[22:18:04] <guillem> bn_: there are many source of undeterminism, see https://wiki.debian.org/ReproducibleBuilds/Howto[22:18:16] <guillem> for a list, I'm not sure though if it's fully up-to-date[22:18:21] *** schwehr <schwehr!~schwehr@c-24-4-248-21.hsd1.ca.comcast.net> has quit IRC (Quit: schwehr)[22:21:00] <guillem> bn_: ah the up-to-date list in case you are intersted: https://anonscm.debian.org/cgit/reproducible/notes.git/tree/issues.yml :)[22:25:10] *** schwehr <schwehr!~schwehr@c-24-4-248-21.hsd1.ca.comcast.net> has joined #fink[22:28:56] <bn_> dmacks_: "reverse dependencies" as in build-time, "of a package" as in one that is currently installed, yeah[22:39:47] <dmacks_> 'fink dumpinfo -fdepends,builddepends FOO'[22:40:25] <dmacks_> er, hold on, that will miss some.[22:41:12] <dmacks_> 'fink show-deps FOO' (because to build FOO you need dep info about other packages that are built together with it (splitoff pkgs))[22:42:08] <dmacks_> ...the idea of building the family, not just the one pkg itself. But for building, it doesn't matter whether the package you are querying is installed or not.[22:43:07] <dmacks_> For others reading this, fink does not use debian tools for building, so there is no way to use dpkg or apt to learn build-deps[22:51:46] <bn_> but I thought that only shows forward dependencies, not reverse?[22:53:31] *** asmeurer <asmeurer!~asmeurer@71.68.151.43> has joined #fink[22:54:04] <dmacks_> ah crap, I misread the Q[22:55:46] <dmacks_> You'd have to parse 'dpkg list FOO --format=dotty-build'[22:56:39] <dmacks_> Er even worse. 'dpkg list --format=dotty-build'[22:56:56] <dmacks_> Then grep to find FOO on the right side.[22:58:00] <dmacks_> ...then interrogate dpkg to find which of the left-side of them are installed.[22:58:11] <dmacks_> And I meant 'fink' not 'dpkg' first.[22:59:05] <dmacks_> So (untested): dpkg -l `fink list --format=dotty-build | grep ' "FOO"' | cut -d\" -f2 | uniq`[23:00:44] <bn_> yeah, I was afraid of that, was hoping there was something already built in VS manually querying the L-side results of the grep :)[23:01:26] <dmacks_> :([23:02:21] <bn_> ah, I forgot about cut[23:07:32] *** asmeurer <asmeurer!~asmeurer@71.68.151.43> has quit IRC (Quit: asmeurer)[23:19:31] <bn_> I think that worked[23:30:58] *** mischi <mischi!~michael@185.98.49.17> has quit IRC (Quit: mischi)[23:31:13] *** mischi <mischi!~michael@185.98.49.17> has joined #fink[23:31:25] <SnaggleAway> bn_: check /sw/etc/fink.conf for the Buildpath field to know where Fink packages get build (I believe it defaults to /sw/src/SOMETHING.build (not sure what SOMETHING is because I use a non-default path))[23:31:46] *** mischi <mischi!~michael@185.98.49.17> has quit IRC (Client Quit)[23:32:00] *** mischi <mischi!~michael@185.98.49.17> has joined #fink[23:32:34] *** mischi <mischi!~michael@185.98.49.17> has quit IRC (Client Quit)[23:32:48] *** mischi <mischi!~michael@185.98.49.17> has joined #fink[23:33:22] *** mischi <mischi!~michael@185.98.49.17> has quit IRC (Client Quit)[23:33:36] <bn_> so as far as installed stuff goes: tetex-texmf is depended on by libkpathsea4 and almost 100+ (!) installed packages depend on that? :([23:33:37] *** mischi <mischi!~michael@185.98.49.17> has joined #fink[23:34:05] <SnaggleAway> “obsolete” source files are for any tarball which none of the current active .info files reference. So if FOO-1.1.tar.gz is present, but the latest version of Foo that Fink knows about is foo-1.2, then FOO-1.1.tar.gz would get removed by fink —cleanup. But if you’re on 10.5, then it’s very likely that all your source files are the latest that dists/10.5-EOL knows about.[23:34:11] *** mischi <mischi!~michael@185.98.49.17> has quit IRC (Client Quit)[23:34:26] *** mischi <mischi!~michael@185.98.49.17> has joined #fink[23:34:44] <bn_> tar, sed, even fink?[23:34:59] *** mischi <mischi!~michael@185.98.49.17> has quit IRC (Client Quit)[23:35:13] <SnaggleAway> ?[23:35:14] *** mischi <mischi!~michael@185.98.49.17> has joined #fink[23:35:20] <bn_> SnaggleAway: I think you're right, I later saw a /sw/src/fink.build dir[23:35:47] *** mischi <mischi!~michael@185.98.49.17> has quit IRC (Client Quit)[23:36:01] *** mischi <mischi!~michael@185.98.49.17> has joined #fink[23:36:15] <bn_> "tar, sed, even fink" <- was referring to my previous comment[23:36:35] *** mischi <mischi!~michael@185.98.49.17> has quit IRC (Client Quit)[23:36:40] <SnaggleAway> tetex-texmf?[23:36:40] <bn_> SnaggleAway: so what if I have newer tarballs in there?[23:38:00] <bn_> yeah, trying to see if I can delete the tarball for that, doesn't seem like something I use? but apparently a reverse dependency check shows a whole bunch of stuff that requires it, including tar, sed, and even fink??[23:38:10] <bn_> s/I use/I'd use/[23:38:11] <Melian> bn_ meant: yeah, trying to see if I can delete the tarball for that, doesn't seem like something I'd use? but apparently a reverse dependency check shows a whole bunch of stuff that requires it, including tar, sed, and even fink??[23:39:18] <dmacks_> Lots of packages build their documentation from source/templates in their tarball, so the documentation formatter/building tools are BuildDepends of those packages.[23:39:54] <dmacks_> You can delete the source tarball of *everything*, even packages that are still current. Once you have a binary .deb, you don't need to recompile it:)[23:40:14] <SnaggleAway> also, none of fink, sed, or tar use tetex[23:42:38] <bn_> SnaggleAway: is dmacks_ script not correct? or did I use it incorectly? I basically started with FOO = tetex-texmf and it showed libkpathsea4 as an installed build dependency, I then set FOO = libkpathsea4 and ran the script again to see what depended on that[23:42:52] <bn_> and that's where I got that huge list[23:43:59] <SnaggleAway> maybe it’s being read backwards (that libkpathsea4 need tar/sed/fink, rather than the other way around)?[23:50:22] <dmacks_> fink list --format=dotty-build | grep ' "tetex-texmf"'[23:50:34] <dmacks_> only gives me "coq-doc" -> "tetex-texmf";[23:51:27] *** schwehr <schwehr!~schwehr@c-24-4-248-21.hsd1.ca.comcast.net> has quit IRC (Quit: schwehr)[23:51:38] <bn_> SnaggleAway: fink cleanup -d still output a bunch of lines regarding what it considered obsolete src files, so I guess still some leftover tarballs and .debs from old versions[23:51:47] <bn_> s/src//[23:51:47] <Melian> bn_ meant: SnaggleAway: fink cleanup -d still output a bunch of lines regarding what it considered obsolete files, so I guess still some leftover tarballs and .debs from old versions[23:52:27] <dmacks_> But I won't have coq-doc installed for a while to be able to test further.[23:52:29] <bn_> just want to make sure it didn't blow away anything new I manually dropped into /sw/src[23:52:43] <bn_> s/want/wanted/[23:52:44] <Melian> bn_ meant: just wanted to make sure it didn't blow away anything new I manually dropped into /sw/src[23:53:27] <bn_> dmacks_: yeah, for me I get:[23:53:40] <bn_> ||/ Name Version Description[23:53:40] <bn_> +++-=================================-=================================-==================================================================================[23:53:40] <bn_> un carlisle <none> (no description available)[23:53:40] <bn_> No packages found matching coq-doc.[23:53:40] <bn_> No packages found matching doxygen1.3.[23:53:40] <bn_> No packages found matching gfont.[23:53:40] <bn_> un hyperref <none> (no description available)[23:53:41] <bn_> No packages found matching latex-make.[23:53:41] <bn_> ii libkpathsea4 3.5.6-1 Path search library for TeX[23:53:42] <bn_> ii libkpathsea4-shlibs 3.5.6-1 Shared libraries of path search library for TeX[23:53:42] <bn_> No packages found matching libkpathsea6.[23:53:44] <bn_> No packages found matching libkpathsea6-shlibs.[23:53:44] <bn_> un natbib <none> (no description available)[23:53:44] <bn_> un oberdiek <none> (no description available)[23:53:44] <bn_> No packages found matching pdfscreen.[23:54:09] <bn_> crap, did that get truncated?[23:54:35] <dmacks_> For 'dpkg -l coq-doc'?? (pastebin would help make this more legible)[23:54:46] * dmacks_ gotta run, back in a few hr[23:54:51] *** dmacks_ is now known as dmacks_away[23:55:11] <bn_> no, for tetex-texmf[23:55:38] * dmacks_away doesn't understand, but among other things perhaps dpkg does substringing of the packagenames?[23:58:30] <bn_> http://pastebin.com/iS1EE1nh[23:59:15] <bn_> substringing?