Re: Moving to synth (was: Removing documentation)
Greg 'groggy' Lehey wrote:
> So how would things improve in this respect if we change to synth?
> There we need a maintainer who understands Ada. OK, at the moment
> that's you. But what happens when you relinquish maintainership for
> whatever reason?
> My feeling on the matter is that there's space for more than one tool,
> as Mathias suggested. But I think it would help synth to have
> user-oriented documentation similar to that for portmaster or
> portupgrade ("to achieve this, do this..."). I could see this as a
> good addition to the handbook (4.5.3.3). A(n objective) discussion of
> the pros and cons of the three alternatives would also be useful.
Having been in the situation of doing such a discussion some 10 years ago,
when portupgrade and portmaster were the fashionable tools, and pkgng
did not exist, i was very interested to discover this tool synth that i
had never heard of.
Of course unable to find it in the ports i finally found it was a
DragonFly port very recently
ported to FreeBSD, and then that it was written in Ada. Next task find
the Ada compiler.
Needless to say, no port named ada under lang, finally found it was
gcc5-aux. Downloaded
the packages for gcc5-aux and ncurses the port for synth from SVN
repository, and began compiling.
Somewhere the build broke because of unsupported
pragma Suppress (Tampering_Check);
but after removing this line i had finally a brand new synth.
Frankly one first prerequisite for having this discussion is that the
*package* synth is ready to be downloaded
and people don't have to go through this ordeal.
Immediately i wanted to test it on a port which is not too much
connected to other stuff
so i did after synth configure
synth status
and
synth build lang/chicken.
The first one bombed since there was a problem with the options on some
port. I solved it as required and
synth status gave some answer.
Then the second one decided it needed to recompile 6 ports and started
doing it. The nice curses
screen appeared, which for sure is beautiful but doesn't say much about
what is going on.
Fortunately i discovered beautiful logs under /var/log/synth, and
apparently the 6 builds went OK.
Then it asked me to scan the ports tree which took ages, finally to
discover that my builds failed
"option check" and do nothing.
This prompted me to try understanding what the crap synth was doing, and
i finally found that the
"repository" was the place under /usr/obj where synth moved all the
packages it had compiled, that
there was a ton of mounts under /usr/obj reproducing a clean room
freebsd system to compile the port.
That the long operation above consisted in running make -V in a lot of
ports to discover the value
of certain variables which is usually done to compute the INDEX in
/usr/ports, and that, due to the
above failure the corresponding packages had been removed from the
repository. Part of this information
i obtained by looking at the code which is surprisingly readable for
someone who doesn't know ada.
The exact
This little story leads me to a second prerequisite, produce a more
complete documentation describing exactly
what synth does, how to solve buggy situations etc. The argument "the
soft can be directly used by newbies
without documentation" i don't buy.
Finally lets us target the center. I like very much the idea of using
these mounts to compile the packages.
It is fast and simpler than jails. I also like the idea of doing several
things simultaneously. Is it really necessary
to use thousands and thousands of lines of code to do that? Concerning
the objection that portmaster
has no dependency while synth has dependencies i think this objection
has no merit since it is a binary
which will run without problem, its data structures being in memory.
This is in great contrast with portupgrade
where if you upgrade ruby when portupgrade runs, you are in a mess (or
if you upgrade the db that
portupgrade uses). I have not seen if synth checks for circular
dependencies, portupgrade certainly
did it.
In summary, synth seems to be a very nice work. As an exercice in shell
writing, portmaster is
certainly a master's work, but it is a poor substitute to a real
management tool. Portupgrade
was more ambitious, but had too many problems and was incredibly slow.
So i think J. Marino
is right, better bite the bullet as soon as possible, polish whatever
needs polishing, update the documentation
and go ahead. The fact that synth is written in a relatively obscure
language can be a deterrent,
but in fact it is very readable by non ada practitioners.
--
Michel Talon
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
Le 6 févr. 2014 à 13:27, Julian H. Stacey a écrit : you = have to spend a couple of minutes learning the basic SQL queries, which is no more difficult that learning = obtuse find and grep options. Package addicts were so myopic they ignored some people won't even use packages, just /usr/ports make. local.sqlite was immaturely shoved in without documenting it, no man 5 local.sqlite no hook there for the couple of minutes learning you assert, (no hook to believe the couple you assert). First please excuse me, this message is posted via an Apple mail system. So how to interact with local.sqlite? niobe% sqlite3 local.sqlite SQLite version 3.8.2 2013-12-06 14:53:30 Enter .help for instructions Enter SQL statements terminated with a ; sqlite .tables annotation options pkg_script categories packages pkg_shlibs deps pkg_annotation pkg_shlibs_provided directories pkg_categories pkg_shlibs_required filespkg_directories pkg_users groups pkg_groups script licenses pkg_licenses scripts mtreepkg_option shlibs option pkg_option_default users option_desc pkg_option_desc sqlite .schema packages CREATE TABLE packages (id INTEGER PRIMARY KEY,origin TEXT UNIQUE NOT NULL,name TEXT NOT NULL,version TEXT NOT NULL,comment TEXT NOT NULL,desc TEXT NOT NULL,mtree_id INTEGER REFERENCES mtree(id) ON DELETE RESTRICT ON UPDATE CASCADE,message TEXT,arch TEXT NOT NULL,maintainer TEXT NOT NULL, www TEXT,prefix TEXT NOT NULL,flatsize INTEGER NOT NULL,automatic INTEGER NOT NULL,locked INTEGER NOT NULL DEFAULT 0,licenselogic INTEGER NOT NULL,time INTEGER, manifestdigest TEXT NULL, pkg_format_version INTEGER); CREATE INDEX pkg_digest_id ON packages(origin, manifestdigest); sqlite select name,version from packages limit 10; pkg|1.2.5 xproto|7.0.25 xextproto|7.2.1 xbitmaps|1.1.1 renderproto|0.11.1 libXdmcp|1.1.1 libXau|1.0.8 libxml2|2.8.0_3 libpthread-stubs|0.3_4 kbproto|1.0.6 and to replace grepping sqlite select name,version from packages where name like '%kde%' limit 10; kdehier4|1.1.1_1 kde4-wallpapers-freebsd|1.0 pam_kde|1.0 kde4-xdg-env|1.0.1 kde4-icons-oxygen|4.10.5 kde4-shared-mime-info|1.2 kdelibs|4.10.5_2 kde-wallpapers|4.10.5 kde-base-artwork|4.10.5 polkit-kde|0.99.1 sqlite .quit niobe% From this it is easy to experiment, and the full sqlite documentation is at: http://www.sqlite.org/lang.html -- Michel Talon ta...@lpthe.jussieu.fr smime.p7s Description: S/MIME cryptographic signature
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
ports/ is not just for package addicts. I never install packages, but only build install from ports/. sqlite junk obstructs /var/db/pkg being accessed by find grep to debug breaking ports builds. As someone who has advocated the use of sqlite to replace the old database in the filesystem several years before it has been implemented by the new package system, i can only conclude, like Matthew that you are being absurd. The old package system was total crap, incredibly slow and using system resources in absurd ways. Sqlite obstructs nothing, you have to spend a couple of minutes learning the basic SQL queries, which is no more difficult that learning obtuse find and grep options. Moreover i have hard time believing one needs to dissect the package system (beyond reading the output of pkg info) to debug a port build. One surely needs some knowledge of make, C, perhaps C++ which is vastly more difficult than figuring how to extract the content of the sqlite database. Finally i confess i am a package addict. Insisting that people use packages is the best way to ensure that the ports can indeed be built and that the result works. I have spent too many hours editing C files and makefiles in the past in the hope of getting something to build, now i want that it just works, like it does with the likes of Debian, etc. I am very grateful to Baptiste, Matthew and al. to the excellent job they have done, finally FreeBSD has a decent infrastructure for external software. The new package system is fast, efficient, and very importantly lists all the things it will do before doing them (like Debian apt), which allows to avoid ruining a working system, a very common occurrence in the old package system. So it does most of the things that i thought were necessary to come to parity with apt, and is light years ahead of the old system. -- Michel Talon ta...@lpthe.jussieu.fr smime.p7s Description: S/MIME cryptographic signature
Re: Any newer latex than latex2e-2003.12_1
You can install dvipsk-tetex. By the way you can also run maxima in GUI mode by running wxMaxima. All of them nicely available in precompiled form thanks to the excellent work of the FreeBSD team. The new pkg system is wonderful, finally FreeBSD is on par with Debian or ArchLinux for ease of use. -- Michel Talon ta...@lpthe.jussieu.fr smime.p7s Description: S/MIME cryptographic signature
Graphing installed ports
The following script http://www.lpthe.jussieu.fr/~talon/check_pkg.py does the job you want plus other things, but it was written for the old package system (i.e. it looks under /var/db/pkg). By the way i noted that as soon as you have a fair number of ports installed, you get so many arrows in the diagram that you cannot see anything, rendering the idea quite useless. I hoped one could discover islands with little interconnections between them but in fact mostly everything becomes connected by dependency. -- Michel Talon ta...@lpthe.jussieu.fr smime.p7s Description: S/MIME cryptographic signature
Re: [HEADSUP CFT] pkg 1.0rc1 and schedule
Doug Barton wrote: What I'm looking for is compelling motivation to make this overwhelming change to the ports infrastructure. Because the present state of the ports system is not a compelling enough reason? My arms are falling … -- Michel Talon ta...@lpthe.jussieu.fr
Re: Port suggestion: REDUCE (math) is available under a BSD license
See http://lists.freebsd.org/pipermail/freebsd-ports/2011-December/071814.html -- Michel Talon ta...@lpthe.jussieu.fr ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please update lang/cmucl to 20c
any chance to see cmucl-20c (including cmucl-extras) in ports, while at the same time keeping the current lang/cmucl as, say, lang/cmucl19, because that version still supports non-SSE2 CPUs? The sse2 version is indeed much faster, and works on quite old computers nowadays so i am not sure that the generic version is still useful. And while I'm asking for it, could the cmucl port include the sources (perhaps from the source release tar ball or as part of the building-from-source process?) in such a way that it is available from within lisp itself? In fact the exact position of the source code from which the binary has been compiled is annotated in the binary, so the only solution to make debugging, etc. work is to avoid completely moving the source code after compilation. So practically you have to compile cmucl (or sbcl) in your home and live it here. The ports system is useless here. -- Michel Talon ta...@lpthe.jussieu.fr ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: A new and better way to do make readmes?
Matthew Seaman said The big problem with performance in all this INDEX and README.html building is that it takes quite a long time relatively to run make(1) within any port or category directory. make(1) has to read in a lot of other files and stat(2) many more[*] -- all of which involves a lot of random-access disk IO, and that's always going to take quite a lot of time. Now, doing 'make readme' in a category directory doesn't just run make in that directory, but also in every port in that category. Popular categories can contain many hundreds of ports. Maybe I should add README.html generation to my FreeBSD::Portindex stuff. Should be pretty simple -- all the necessary bits are readily available and it is just a matter of formatting it as HTML and printing it out. Indeed, the following python script http://www.lpthe.jussieu.fr/~talon/show_index.py parses the index in a few seconds and can display exactly the same information as the readme.html on demand in a web browser, which is far cleaner than polluting the ports tree with the readmes. Alternatively i have a fcgi version that can be coupled to web servers supporting fcgi like lighttpd. http://www.lpthe.jussieu.fr/~talon/show_index.fcgi Already 5 years this was done ... -- Michel Talon ta...@lpthe.jussieu.fr ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Is there a port to math/reduce?
the computer algebra system (CAS) REDUCE has been released as open source software [*], but AFAICS, it has not yet been ported to FreeBSD. Anyone with porting skills interested to have a look? I have tried and apparently succeeded in building reduce on FreeBSD. Here is what i get: niobe% bin/redcsl Reduce (Free CSL version), 13-Dec-11 ... 1: (x+y)^4; 4 32 234 x + 4*x *y + 6*x *y + 4*x*y + y What i have done: downloaded reduce from subversion, then you have the choice of two lisps to build reduce psl and csl. Since i don't know how to get psl for FreeBSD i have done configure --with-csl gmake (note Gnu make). This does a lot of configuration, then builds the fox toolkit and then builds csl. Here i got two errors. One is in reduce-algebra/trunk/csl/cslbase/fns1.c One needs to add #include sys/time.h for example after headers.h, otherwise timeval is unknown later on. The second is about RLIM_SAVED_MAX and RLIM_SAVED_CUR undefined in reduce-algebra/trunk/csl/cslbase/csl.c These are resource limits related to getrlimit(), which don't exist as such in FreeBSD. I have replaced the test at lines 1417 1418 by if (stackLimit != RLIMIT_VMEM) which i hope is correct. Then csl builds to the end and then reduce builds. At the end you get: Info: Recompilation complete if test -f reduce.app/Contents/reduce.img; \ then cp reduce.app/Contents/reduce.img /home/michel/pub/reduce-algebra/trunk/csl/cslbase/../../cslbuild/generated-c; \ elif test -f reduce.img; then cp reduce.img /home/michel/pub/reduce-algebra/trunk/csl/cslbase/../../cslbuild/generated-c; fi scripts/make.sh: arith: syntax error: 00 ? 0 : 0 I was puzzled by that, but in fact it means the build of reduce is completed. At this point you can run reduce as above. Now gmake install doesn't work and produces an infinite number of submakes. I don't know how to make a proper install. Hope this may help you to do a port -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: How to resurrect ltrace from Attic?
Note that the source code can be obtained from Debian, apparently. Does it work, i don't know. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Detecting dependencies
Oliver Fromme wrote: That's what a script of mine does (it's also in Python): http://www.secnetix.de/olli/scripts/pkg_dep_view Waooh! this is very cute. While we are in python i have something which draws graphviz dependency graphs for ports here http://www.lpthe.jussieu.fr/~talon/pkg_check.py Unfortunately for many ports the diagram becomes completely unreadable. Your display is wonderful. Seeing things like your script, the perl script port-easy by des, etc. i really wonder why people write stuff in C or worse shell for ports. One could write ten times smarter and ten times shorter things in real languages like python, lisp, etc. This argument of being included in base system is so completely bogus ... -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: testing PKGNG
Sergio wrote: I moved all my servers (about 40) to the pkgng (new generation) package/port system, and I can say that it is amazing... it is not yet finish, and have some minor issues, but works very well, and is lightning fast.. It is almost the same as pacman (from Archlinux).. you build a repository and install packages from that repository. when you update the repository, the other servers can do an upgrade.. you do not have to have the ports tree in each server, and you build the ports only on the master server in the master server, there is a full gnome2 (with 842 dependencies) that install right on the shelf with only one command: pkg install gnome2 now I have a full functional server runing gnome, libreoffice, inkscape hplip, cups printing, gdm... in about 30 minutes from internet I am extremely interested by what you are saying here. Do you mean that you can find somewhere precompiled packages that you can install in 30mn or that you use packages compiled on a master server? Of course the difference is that if you have just one machine in the basement instead of a server farm, the point of view is not the same ... By the way if you mention that pkgng shares something to some penguinist system, beware it will be villified by some guardians of the orthodoxy who are quite vocal. Anyways if it is indeed fast it will make a happy difference with the present pkg-* tools. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports-system priorities rant (Re: sysutils/cfs)
Mikhail T. wrote: Having to deal with RedHat's yum at work, I got to say, I'd rather be building from source, than installing from consistent packages, that somebody else built *to their* tastes. Fedora crap is a very bad example. The canonical example of a binary distribution which *works* is Debian. You can always very easily compile a source Debian package to *your* taste, almost as easily as a FreeBSD port. You don't need to compile the hundreds of packages that sit on your hard disk, maybe you are interested in tweaking a couple of ports to your liking and you get the benefit of a much faster installation and upgrade of all the pristine packages. No, I don't want FreeBSD to go in that direction at all. Let RedHat cater to that market While i think that going in this direction will be very beneficial to FreeBSD and that ReHat doesn't come anywhere close to cater to this market (i work in a lab which is almost 100% RedHat since many years, and i am not happy at all with that. As much as Ubuntu is despised here, it is light years ahead of the Fedora always beta stuff). -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports, take 2
Ruslan wrote: Hi, i maintain port (sysutils/rdup) that is failing with clang: I have looked at the problem, it is indeed in rdup source. If you look at rdup git history for rdup-tr.c you will see remove rdup_entry_c from the code, totally unneeded in this modification, the line rdup_entry_c = rdup_entry; which makes sense is (probably automatically) replaced by the line rdup_entry = rdup_entry; which is superfluous. gcc doesn't bark at that while clang does. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: suggestion for pkgdb from ports-mgmt/portupgrade: add more explanation
Robert Huff said: Michel TALON writes: Finally the file UPDATING should be forcefully removed from the system While I support all reasonable efforts to get automation to always Do The Right Thing(tm), my reaction to this is: absolutely not. Until you can show there are no, and will never again be, edge cases which break the system, documention for human invervention is always the right choice. Your answer is very interesting and allows me to go further in the reasoning. Indeed the UPDATING file is here to solve edge cases. My point is that there shouldn't be any edge cases, if there are some it is because something somewhere has been ill designed, which is not so suprising since the system has been conceived by Jordan Hubbard when the number and complexity of ports was much smaller. I certainly don't have any precise idea of the things which should be changed so that edge cases disappear, only *very experienced* people having observed a lot of failure cases could give correct advices. It is not impossible to design a system which works automatically without having any recourse to manual intervention, after all, as much as it may displease some people here, it is a fact that Debian works this way (and Debian-like systems like Ubuntu). Having a file which documents manual intervention is a perpetual tentation to do the things the sloppy way, which in fact frequently occurs in FreeBSD. As long as such a behavior continues, the authors of portupgrade, portmaster etc. are building on sand. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: suggestion for pkgdb from ports-mgmt/portupgrade: add more explanation
Julian H. Stacey wrote: Suggestion: pkgdb is too cryptic even with -v, it needs more explanation what it is up to particularly what decisions it asks from user . This is a point i have studied a long time, notably i have read the ruby code doing that. There are a lot of heuristics doing automatic choices, when they fail they ask the end user. The whole stuff is quite complicated, and asking questions to the user is certainly not the solution, since he has no business knowing the necessary details. In practice he does arbitrary (usually bad) choices and the system degrades. In general one should always be able to make these decisions automatically using the MOVED file, which is what portmaster does (barring some exceptions which occur from time to time and are supposed to be documented in UPDATING - which is an offense to the automaticity of the system). I thing that portupgrade should be modified to remove all those heuristics and use MOVED, but the code is not so obvious to understand, and ruby (as far as i am concerned) doesn't help. Finally the file UPDATING should be forcefully removed from the system, and ports maintainers should get at the same effect through means which don't prevent automatisation (for example upping the revision levels of all appropriate ports, even if they are very numerous). At the end of the day, portupgrade is so awfully slow that i think moving away from ruby could also help in this respect. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ports system quality
Chad Perrin wrote: Of course, your goal is apparently to convince me that yours are the correct priorities. Indeed i think having the correct priorities is essential when choosing between different options, and i am sincerely convinced that my choices are shared by a lot more people than yours. For example, having less bloat in the system doesn't even appear in the radar of most people. I value much more that hardware is supported, that installation and upgrade are easy, troubleless. Like everyone else i am irritated by some developments in the Ubuntu experience, for example the parallel booting stuff, which doesn't work well (but that people would like to imitate in FreeBSD), but all those problems remain minor. A few days ago i went to a store to buy a new laptop, i went with two CDROMs, an Ubuntu one and a FreeBSD one. Guess which of the two supported the network controllers in the laptops i tried? -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ports system quality
Chad Perrin said: On Mon, Aug 29, 2011 at 12:17:12AM -0700, Doug Barton wrote: FreeBSD needs to get better in this area, but I seriously doubt it will ever be as easy and painless as something like ubuntu. For a great many use cases, Ubuntu is one of the most painful desktop user experiences I have ever encountered. Please, *please* do not emulate Ubuntu. Any discussion on such subjects should begin by switching off the reality distortion field. For *my own experience* Ubuntu works perfectly OK, in particular all the hardware on my laptop works, suspend works, i have zero problem keeping the ports updated, etc. It is the completely no fuss solution. Wether FreeBSD needs to go in a direction or another is a different subject, but *please* be objective in your descriptions. By the way: it installs software and runs servers the user will never have any occasion to use, with no obvious way to deactivate them; and it essentially enforces the use of huge collections of software by way of hopelessly intertangled dependencies. is a sentence you can easily apply to any modern system. And most users could not care less that there is *bloat* on their hard disk. Anyways you can find a functional and installable desktop Ubuntu system on a simple CDROM, show me the same for FreeBSD and i will happily conclude it is less bloated. And for the same price you have on said CDROM a live system and an installer which is not a joke like FreeBSD one. Wonder why one system has more users than the other ... -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
ruby-rbtree
It appears ruby-rbtree is marked deprecated because the master site has disappeared. In fact it has moved here: http://rubyforge.org/frs/download.php/67118/rbtree-0.3.0.tar.gz -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD unmaintained ports which are currently scheduled for deletion
I notice in the list the port math/pari which is not some obscure abandonware, but one of the most proeminent free computer algebra software. So i look at the pari web page and then: niobe% fetch http://pari.math.u-bordeaux.fr/pub/pari/unix/pari-2.5.0.tar.gz pari-2.5.0.tar.gz 100% of 2650 kB 6412 kBps . niobe% ./Configure Configuring pari-2.5.0 (STABLE) Ok. Type make install when you are ready Bye ! niobe% gmake gp Making gp in Ofreebsd-i386 niobe% cd Ofreebsd-i386 niobe% gp-dyn GP/PARI CALCULATOR Version 2.5.0 (released) i386 running freebsd (ix86/GMP-5.0.1 kernel) 32-bit version compiled: Aug 21 2011, gcc-4.2.1 20070719 [FreeBSD] (readline v6.1 enabled, extended help enabled) Copyright (C) 2000-2011 The PARI Group PARI/GP is free software, covered by the GNU General Public License, and comes WITHOUT ANY WARRANTY WHATSOEVER. Type ? for help, \q to quit. Type ?12 for how to get moral (and possibly technical) support. parisize = 400, primelimit = 500509 ? 5*6 %1 = 30 ? In other words everything works completely out of the box, without any intervention. After that people will say that the freebsd ports are the best thing since sliced bread! -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD unmaintained ports which are currently scheduled for deletion
Kurt Jaeger wrote:
Looks like the outdated version we have in ports isn't kept there any
more. Would you like to be the port's new maintainer?
I'll have a look at it.
I have played a little with the FreeBSD port for pari:
One needs to modify very little the Makefile:
CONFIGURE_ARGS= --prefix=${PREFIX} --share-prefix=${PREFIX}/share\
--mandir=${PREFIX}/man/man1 --with-gmp=${LOCALBASE}
This is so that the man pages go to the correct position.
MAJOR_VERSION= 2
MINOR_VERSION= 5
REV_VERSION=0
I think all the emacs stuff has become useless.
The good distinfo is
niobe# cat distinfo
MD5 (pari-2.5.0.tar.gz) = 6077c6db56fdd32e39a06a9bf320e1f7
SHA256 (pari-2.5.0.tar.gz) =
5dc923b001ca0f8664facfafcd91946be63faf8f0e1df4b11bfac80f89ec37a2
MD5 (pari-2.5.0.tar.gz) = 0b595a1345679ff482785a686c863e9f
SIZE (pari-2.5.0.tar.gz) = 2714449
The patch files in files/ don't apply cleanly and are useless, except
patch-config-TOP_Make.SH
which removes compiling the doc. This may be fine because the doc is on
the web site, and requires TeX for compiling. Anyways the doc
compile needs make - gmake (and then works) but i don't know how to
pass that to the system.
The make install installs less files than what is in pkg-plist.
In /usr/local/bin:
gp gp-2.5 gphelp tex2mail
In /usr/local/include/pari
genpari.h pari.h paricfg.h paridecl.h parigen.h parinf.h
paripriv.h parisys.h
mpinl.hparicast.h paricom.h parierr.h pariinl.h pariold.h
paristio.h paritune.h
In /usr/local/share/pari:
niobe# ls -R /usr/local/share/pari
PARI doc examples misc pari.desc
/usr/local/share/pari/PARI:
822.pm
/usr/local/share/pari/doc:
Makefile appd.tex parimacro.tex refcard.pstutorial.dvi
users.tex usersch3.tex
appa.tex libpari.dvi pdfmacs.tex refcard.tex tutorial.tex
usersch1.tex usersch4.tex
appb.tex paricfg.tex refcard.dvi translations users.dvi
usersch2.tex usersch5.tex
/usr/local/share/pari/examples:
EXPLAIN Makefilecl.gp contfrac.gp lucas.gpsqufof.gp
Inputrc bench.gpclassno.gp extgcd.crho.gp taylor.gp
/usr/local/share/pari/misc:
READMEcolor.dft gpalias gpfloggprc.dft pari.xpm xgp
niobe# ls -R /usr/local/share/pari
PARI doc examples misc pari.desc
/usr/local/share/pari/PARI:
822.pm
/usr/local/share/pari/doc:
Makefile appd.tex parimacro.tex refcard.pstutorial.dvi
users.tex usersch3.tex
appa.tex libpari.dvi pdfmacs.tex refcard.tex tutorial.tex
usersch1.tex usersch4.tex
appb.tex paricfg.tex refcard.dvi translations users.dvi
usersch2.tex usersch5.tex
/usr/local/share/pari/examples:
EXPLAIN Makefilecl.gp contfrac.gp lucas.gpsqufof.gp
Inputrc bench.gpclassno.gp extgcd.crho.gp taylor.gp
/usr/local/share/pari/misc:
READMEcolor.dft gpalias gpfloggprc.dft pari.xpm xgp
And finally the man pages in /usr/local/man/man1
gp-2.5.1 gp.1 gphelp.1 pari.1 tex2mail.1
and the compressed versions.
Good luck
--
Michel TALON
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: UPDATING 20110730
Doug wrote: Unfortunately the only way to improve on this would be to not do the checks on a port-by-port basis, and do them all together at the end. While that sounds appealing, it would dramatically increase the code complexity, and also dramatically increase the chances of leaving the pkg files in an inconsistent state if the process gets interrupted. I don't like either one of those options. In here i have a program which checks the +REQUIRED_BY files and fixes the origins in +CONTENTS http://www.lpthe.jussieu.fr/~talon/check_pkg.py proceeding globally as you describe above. It would not make a big difference to completely fix the +CONTENTS. On an old machine with around +1000 ports installed it takes of the order of 10-30 seconds to run. Of course this is very fast because it uses the information in the INDEX file. If one accepts to download the INDEX (like portupgrade does) this is no problem. If one wants to rebuild the index from the ports, it takes time, but one can build a partial index for the installed ports (and dependencies). This is done in http://www.lpthe.jussieu.fr/~talon/pkgupgrade and takes someting like 1-2mn on the same machine. So there are ways to speed up the bookeeping done by programs like portupgrade, portmaster, but, as you are saying, doing this job between *each* port upgrade is far more time consuming. Of course the complexity is also increased, perhaps shell scripting is not the good tool to do that i don't know. Moreover i am not convinced that continually forking tons of programs can be very fast, and it would be nice to be able to exploit parallelism on modern multiproc machines. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: UPDATING 20110730
Le Monday 01 August 2011, Doug wrote: A lot of people say that, but I'll stack it up against just about any interpreted language. Some of my routines are actually faster than the equivalents in pkg_info (which is why I use them). Yes, i have seen that portmaster is quite fast. I was meaning that shell scripting is not the clearest tool to program complex stuff, but of course this is dependant on each person. As for the pkg* stuff they are written in C, but this is irrelevant enough if they do a lot of IO, or use poorly performing algos. I remember that Marc Espie said that, after having rewritten the OpenBSD equivalents in perl, they were both clearer and more powerful, and much faster. The slowness gripe i have is about portupgrade. This is particularly obvious when running portupgrade -PP, which may take hours to upgrade a machine without spending any time in compilation. As far as i have understood the pkg* tools are presently being rewritten by a FreeBSD team, i hope the new tools will be much better. This being said if an upgrade tool needs to compute (partially) the INDEX, most of the time is spent in running make -V variables in each port, because make has to read and interpret enormous files. I don't see any way to cut on that, or one should need to develop a special purpose version of make to evaluate these variables, perhaps which should keep persistent computations between ports (but this is dangerous). ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: UPDATING 20110730
On Mon, Aug 01, 2011 at 01:59:08PM -0300, Sergio de Almeida Lenzi wrote: Hello Even I use portmaster (a very good piece of software), it becomes very slow when you have 1550 ports installed in your system. As only a few ports (about 100, in my case) changes in a week time, I build a database (postgres) that contains all the ports installed, de depencies and a flag that tells me if that port needs updating (pkg_version) a shell script scans the ports (pkg_info | cut -d ' ' -f 1) and builds the database once a week (can take several hours... Once the database is built, an sql query (only ms...) tells me what to do... it then executes pkg_delete, cd /usr/ports/..., make clean all package.. and after doing all the job, it updates the postgresql database (seconds... ). In my case I use a central server with all the 1550 ports... and all I do is to install them on the slaves, (again, using the postgres database data)... Hope this can give someone some ideas Sergio Some years ago the idea floated around to use a sqlite database to keep a fast access copy of the important data in /var/db/pkg, but this idea was dismissed for various reasons, in particular the fact that the base system has the Berkeley database, or that using the filesystem as a poor man's database was a better idea. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: UPDATING 20110730
On Mon, Aug 01, 2011 at 09:39:05AM -0700, Jos Backus wrote: On Aug 1, 2011 7:10 AM, Michel Talon ta...@lpthe.jussieu.fr wrote: [snip] This being said if an upgrade tool needs to compute (partially) the INDEX, most of the time is spent in running make -V variables in each port, because make has to read and interpret enormous files. I don't see any way to cut on that, or one should need to develop a special purpose version of make to evaluate these variables, perhaps which should keep persistent computations between ports (but this is dangerous). Or don't store lots of data in files in Makefile format. The make language is a poor data storage format that doesn't allow access to that data from other tools easily or efficiently. I'm struggling with a similar problem at $WORK. Jos This is unfortunately impossible because the ports system is organized around a make logic and the relevant dependency variables are only obtained through running make on each ports Makefile *in the context* of the gigantic makefiles (bsd.port.mk, etc) which are included. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
Chris Brennan wrote: On 7/26/2011 3:28 PM, RW wrote: It seems more reasonable than the idea that most people using FreeBSD are doing so despite being very unhappy with FreeBSD ports. If that's= really true then we should give Beastie nipple-clamps and a ball-gag to= better appeal to our key demographic. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org= +1 just because the thought of that is funny as hell! As a testimonial to the diabolical nature of FreeBSD yesterday i have installed a PC with FreeBSD-8.2 RELEASE, using the distributed packages (pkg_add -r). When installing gimp, something went south. After some checks it was avahi-app which refused to install, the reason being that pw groupadd -n avahi failed, with the message: group disappeared during update This from /usr/src/usr.sbin/pw/pw_group.c line 271. How is it that such an error, perhaps due to some concurrent access bug, happens in such an irregular way that it is still present since many years? In my installation, several other packages used pw to add to the group and passwd files (hald, etc.) but the error was triggered only by avahi-app, on the other hand it was 100% reproductible for avahi-app. I have seen this problem many times in the past. The only way i was able to proceed was to run pkg_add -I -r avahi-app after that the other dependencies of gimp and gimp itself installed OK. I don't remember that this error was blocking in this way in the past, but it is very worrisome, i don't see a beginner being able to cope with such problem. Still another problem in my installation i have an inn server which sucks news via newsx. Inn installed OK but newsx doesn't appear on the freebsd repository. I try to compile newsx, of course it fails. The reason? the inn installation lacks all the configuration files under /usr/local/news/etc ! More than that the conf files appear nowhere on the machine! How a user is supposed to figure out how to write such files without the models at hand? I have installed inn several times, i have never seen that. Some maintainer has found judicious to remove the conf files (perhaps to avoid overwriting a preexisting installation, but this is the bad way to solve the problem). Anyways, without etc/inn.conf, newsx cannot compile, since it picks its own configuration from inn.conf. So by doing this change the inn maintainer has broken newsx inadvertently, and of course no one noticed. This is emblematic of many other ports which are mismanaged, introduce tons of unnecessary dependencies which complicate everything, etc. For example, installing the port xorg installed things such as pyton and ruby which have zero relation with the problem at hand. It also installed perl but this is required for autoconfiguration of the server, i think. On the bright side, installing xorg produced a working X11 display without any configuration except running dbusd and hald. I have at least one positive point to report, for the first time i see printing working in wxMaxima, in the past either it didn't work at all or coredumped. So someone has understood the printing problem in the wx toolkit, this is nice. This post is ways too long, but i hope more informative that comments such as Nuts ushered by some phd student who apparently value himself at tremendous heights. As to the poster objection, one may very well use FreeBSD for some other qualities, even if one is not happy with the state of the ports system. And to the more general objection that all this is unrelated to the thread subject, portupgrade, it is *extremely* related, because no upgrading tool can work, be it portupgrade, portmaster, or whatever, in the presence of the sorts of bugs i have described above in the basic ports system. An obvious flaw of portupgrade is that it is very slow, other than that i think it is a pretty good program. Similarly portmaster is a brilliant example of shell scripting and works OK as far as i can see. The real problems are in the ports system itself. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: nscd vs. ports that add user/group (Was: Time to mark portupgrade deprecated?)
On Sat, Jul 30, 2011 at 04:02:55PM +0400, Test Rat wrote: Did you have nscd(8) running at the time? Try invalidating its cache. Nevermind previous patch. This one actually works. You may be perfectly right, i think i have added nscd to the installation after having added hald, etc. but before adding avahi-app. However i have seen such problems in the past, before the introduction of nscd, as far as i remember. %% it's still an ugly hack Index: usr.sbin/pw/pwupd.c === --- usr.sbin/pw/pwupd.c (revision 224499) +++ usr.sbin/pw/pwupd.c (working copy) @@ -191,6 +191,7 @@ pw_update(struct passwd * pwd, char const * user, } } } + system(nscd -I passwd 2/dev/null 2); return rc; } Index: usr.sbin/pw/grupd.c === --- usr.sbin/pw/grupd.c (revision 224499) +++ usr.sbin/pw/grupd.c (working copy) @@ -148,6 +148,7 @@ gr_update(struct group * grp, char const * group, } if (grbuf != NULL) free(grbuf); + system(nscd -I group 2/dev/null 2); return l; } %% Many thanks for the suggestion. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
Jerry wrote: While we are on the subject of port management tools, I still use portmanager when a version bump on a port requires that a massive number of dependencies be rebuild. I have had all too many instances when both portupgrade and portmaster simply bombed out and left me with only a partially updated system, and in many cases, a virtually useless one. Portmanager would simple get the job done right the first time. It might be overkill for one or two port upgrades; however, it works fine on massive projects that seem to bewilder the other two competing contenders. The p5-libwww-5* example in the case of portmaster being a perfect example. This subject of port management tools is a subject i have been much interested in some years ago, and i must say that the problems which seem to surface now in the general consensus, i had discussed them without any echo at the time. Having a system partially updated hence requiring a lot of work to fix with portupgrade happened to me several times. Horrific slowness of portupgrade was perfectly obvious years ago. I think most of the problems come from errors in the ports themselves so are unfixable through ameliorations in the upgrade tools. I think only a more rigorous management of the ports, i mean something like the separation between unstable, testing, stable in Debian, with rigorous procedures for going from one state to the better one could cure this problem, but at the expense of slowing the development. More importantly, only a procedure centered around *binary* packages could possibly lead to a guaranteed decent state of the ports. Centering things around source code can only lead to confusion, incessant messing by both developers and users with various options etc. which can only destabilize the system. Anyways, to come back to port management tools i don't know how portmanager works, but i think that both portupgrade and portmaster have a fundamental flaw in that they both work locally, upgrading one port after another until the job is finished, which means that the state of the machine is constantly modified, possibly into a broken state, without any possibility for the user to know beforehand that he is headed to failure. A proper tool should do a first pass describing exactly the initial state and the final state so that the end user can choose to upgrade or not. This is what Debian apt-get (or aptitude) does, it describes before any destructive action begins what will be removed, what will be installed. This can only work reliably if you have binary packages, otherwise you can never be sure that a source port will compile. The only *BSD i am aware of that has moved in that direction is OpenBSD. From what i hear, people are happy with the management of ports in OpenBSD, while most of people i hear are very unhappy with FreeBSD ports. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
Le mardi 26 juillet 2011 12:38:35, vous avez écrit : Sure, why not kill one of the biggest strengths FreeBSD is known for while we're at it... Or most obvious weakness ... The biggest strength was a good kernel, better than Linux, but this was years ago. Two questions: Who will provide the infrastructure to build me all of my packages the day/hour/moment moment I need them and constantly build me the i386, amd64, athlon-tbird optimized, k8-sse3 optimized, -O2 and -O3 optimized, intel-core optimized, and intel-p3 optimized batches for all of my machines? Who will constantly build and maintain my custom set of binary packages and all their dependencies built with the exact specific OPTIONS that I need and without the components that I don't want? This stuff you are mentioning is the precise reason why people have problems with the ports system. By the way, all your optimisations have next to zero impact on performance, and introduce a sizable probability of bugs. And the components you don't want use an infinitesimal part of your hard disk and nothing in your memory. At the end of the day this sort of feature buys no benefit at all and introduces an infinite combinatoric complexity for people wanting to test the ports system. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Why so many versions of the port science/hdf?
The ports, different from octave, which use hdf, are, i think obtained
from the following:
in /usr/ports
jail1% grep hdf INDEX-8|awk -F | '{print $1}'|grep -v octave
gmsh-2.4.2_5
gmsh-occ-2.4.2_5
salome-5.1.4_1
salome-geom-5.1.4_1
salome-gui-5.1.4_1
salome-jobmanager-5.1.4_1
salome-kernel-5.1.4_1
salome-light-5.1.4_1
salome-med-5.1.4_1
salome-multipr-5.1.4_1
salome-netgenplugin-5.1.4_1
salome-randomizer-5.1.4_1
salome-sierpinsky-5.1.4_1
salome-smesh-5.1.4_1
salome-visu-5.1.4_1
salome-yacs-5.1.4_1
py27-tables-2.2.1
fr-aster-10.3.0.3_1
fr-gibi-2003.2_15
fr-homard-9.8.1
fr-med-2.3.6_3
grads-1.9b4_3
p5-NetCDF-1.2.4
scilab-5.3.1
scilab-toolbox-sivp-0.5.2
scilab-toolbox-swt-0.1.11
sedumi-1.1_3
cdo-1.4.7
cgnslib-2.5.5
ecs-1.3.3_5
fvm-0.12.0_4
gnudatalanguage-0.9_1
hdf-4.2r3_6
hdf-java-2.6.1
hdf5-1.6.9_1
hdf5-1.8.5
ics-1.3.3_2
meep-1.1.1_2
minc-2.0.09_1
mpb-1.4.2_10
ncs-1.3.3_7
netcdf-ftn-4.1.1
netcdf-4.1.1
paraview-3.8.1
py27-h5py-1.2.1_1
py27-netCDF4-0.9.3
hdf-szip-2.1_1
It is easy to get from the same INDEX the required hdf port.
--
Michel TALON
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Dropping maintainership of my ports
Eitan Adler wrote: There is a lot of work that has to be done in the background even if no new ports are added. Things like the gmake upgrade and new ports features take a lot of time. Furthermore adding a port seems to be a trivial task, however the committers have to (a) fix it up if it is formatted badly (b) test it in a tinderbox and only then (c) commit it. This takes more time than just cvs commit. A lot of work has been done in recent years to make this process faster and I'm sure more could be done - but a lot of people don't realize how much work goes on behind the scenes I think it is important to clean up ports because otherwise there is a big burden on the FreeBSD organization, and also on each individual user, when they upgrade their machine. I think on the other hand that some ports are especially important, and don't always receive the care they need, for reasons that i don't know. I have taken some time to look at some ports in the lang category that are unmaintained or are severely old. I have noted that eiffel 13a is deprecated and has an expiration date. Indeed i have found old copies of this software, and it seems that the people doing it have disappeared someway. However at least one is now listed as contributor to gobo-eiffel http://sourceforge.net/projects/gobo-eiffel/ which is not a freebsd port. There is the official eiffelstudio port, which has a valid download link but no maintainer, and smarteiffel which is maintained. I am more interested by the cmucl lisp compiler. In the ports we can find cmucl 19f which is maintained by Martin Cracauer, but is already quite old, and there is no maintainer for cmucl-extras. In fact the cmucl project does the work of providing precompiled stuff for various architectures (the lisp compiler is written in lisp so can only be compiled by a recent enough precompiled compiler, anyways) and in particular one finds freebsd binaries here: http://common-lisp.net/project/cmucl/downloads/snapshots/2011/04/ These binaries are compiled on freebsd_8.1, and there are two versions the unicode version and the non-unicode version, plus the cmucl-extra (localized messages, an adapted editor, called hemlock plus some goodies). So my point is, how is it that cmucl freebsd version finds care and love in the cmucl community, but that this does not extend to an adequate place in the freebsd ports? The other big lisp from the same ancestry, sbcl is better maintained, since the last version is 1.0.47, while freebsd is at 1.0.43, that is 6 months old. These lisps are *very* important for their use in the CAS software maxima, which is actively developed and used by a lot of people (in ancient times the traditional compiler for maxima was gcl but it seems it doesn't work well nowadays, and clisp is far too slow). But they are also important for many other uses, and at this point i see an important omission in the ports system. The standard way nowadys to install lisp packages is to use quicklisp http://www.quicklisp.org/beta/ and after that hundreds of applications can be installed automatically in the same way as cpan does for perl modules. Instead there are a select few lisp applications in the ports, which have a clisp and a sbcl slave port. This is strange. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
This can still be discussed but I don't really like the idea that users may alter packages an installation/extraction time, that would lead to lots of potential buggy installation and report. If user aren't happy with the packaging, they can poke the maintainer, send PR, patch etc. The whole point of *binary* packages is that people don't mess changing options, changing what is installed, etc. so that port maintainers know exactly what people have on their machine, and be able to test it. This is a prerequisite for a system which is not a complete mess. Those you like to change things are on their own. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
Sorry i have just seen a table for dependencies in pkg_repo.c CREATE TABLE deps ( origin TEXT, name TEXT, version TEXT, package_id INTEGER REFERENCES packages(id), PRIMARY KEY (package_id, origin) So this seems fine. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
Julien Laffaye (jlaffaye@) and I, helped by Philippe Pepiot (huge contributor) have been working since the end of the last GSoC on a rewrite of pkg_install. Fantastic! it has been necessary since a looong time. - the register command can analyse elf files when registering a new port to discover forgotten dependencies if necessary. (done in alpha using libelf) Fantastic! the dependencies as mentioned directly in Makefiles by ports maintainers were not always perfect. In term of technology we decided to use a sqlite3 database, and to prevent potential trolling, sqlite3 is used in it's amalgamation form which means it is incorporated in the code sources (as recommanded by sqlite developpers like a statically linked library) on build we only activate the features we need in sqlite. Fantastic! at least using something fast and tested instead of some half-brewed solutions. I have just taken a look at the table packages, it seems that it does not contain dependency information, but you can discover it through analyze_elf, where do you store it? This project is the thing i had dreamed about. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Deprecation campaign
On Thu, Mar 17, 2011 at 07:33:01AM +0300, Ruslan Mahmatkhanov wrote:
17.03.2011 02:33, Michel Talon ??:
Hello,
i noted that ucpp is deprecated because it cannot be fetched
from original site. This is an alternate c preprocessor
supposed to be better than the gnu one, written by Thomas
Pornin. I happen to know the guy (*), so i searched if
the soft had been moved, and indeed it can be found here:
http://code.google.com/p/ucpp/
I hope you may reconsider your decision.
With my best regards
(*) i think he now runs a crypto firm in the Boston area.
I've tried to adopt the port to new distfile..
It builds but doesn't produce ucpp binary.
Maybe you or anybody can look what's wrong.
--
Regards,
Ruslan
I have looked at the question.
First point is that the preprocessor is intended to be run as part of
other tools so does not produce a stand alone preprocessor. However
one may compile it to produce a stand alone executable.
Then one encounters a problem, it does not compile because there are
macros STD_MACROS and STD_ASSERT which are undefined. I have checked the
problem is the same under Linux, maybe this works under Solaris or
whatever. I have replaced that by /usr/include, but assertions don't
work, so i have disabled them. Anyways with the following patch,
one gets a preprocessor ucpp that seems to work OK.
niobe% diff Makefile.new Makefile
81c81
STAND_ALONE = -DSTAND_ALONE
---
#STAND_ALONE = -DSTAND_ALONE
niobe% diff cpp.c.new cpp.c
68,69c68,69
static char *system_macros_def[] = { /usr/include, 0 };
static char *system_assertions_def[] = { , 0 };
---
static char *system_macros_def[] = { STD_MACROS, 0 };
static char *system_assertions_def[] = { STD_ASSERT, 0 };
2367c2367
int system_macros = 0, standard_assertions = 0;
---
int system_macros = 0, standard_assertions = 1;
The *.new files are the files i have modified.
--
Michel TALON
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Deprecation campaign
Hello, i noted that ucpp is deprecated because it cannot be fetched from original site. This is an alternate c preprocessor supposed to be better than the gnu one, written by Thomas Pornin. I happen to know the guy (*), so i searched if the soft had been moved, and indeed it can be found here: http://code.google.com/p/ucpp/ I hope you may reconsider your decision. With my best regards (*) i think he now runs a crypto firm in the Boston area. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: deprecated ports
Ruslan Mahmatkhanov wrote: I also saw that graphics/gimp-greycstoration is finally deprecated. Baptiste you may want to look at ports/154596 to close it. In fact this is an interesting plugin which is superseded by gmic from the same author David Tschumperlé http://gmic.sourceforge.net/gimp.shtml and which is in the ports. So this deprecation is fine. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Superfluous dependencies
Mark Linimon said: On Sat, Mar 12, 2011 at 02:12:34PM -0800, Charlie Kester wrote: I'm not aware of any tool that will display a similar dependency tree for a port *before* it is installed. http://portsmon.freebsd.org/portdependencytree.py Note: it's running a live set of queries on the tree, so it's slow. Wonderful tool! Using it i have found a nice illustration of the title of the thread by looking at the dependencies generated by the ports math/maxima. If you run it you will find *tons* of dependecies. However, being a regular user of maxima, that i compile myself on my machine using cmucl i know that maxima has exactly *one* dependency, a lisp system. Taking the example of cmucl one needs only a previous binary version of cmucl, because it is written in lisp, and the base C compiler to produce the executable lisp. It should not be much different with sbcl, except if one foolishly adjoins unnecessary optional software. When having a lisp, one can in fact compile maxima without even using make, but make simplifies the job. It is not *necessary* to have optional gnuplot (which one may or may not desire), and even less to have (*) graphical front ends like xmaxima or wxmaxima. The teTeX dependency is completely superfluous. I mention this example because it is characteristic of a tendency of many FreeBSD ports to add a kitchen sink of superfluous dependencies which render upgrades and so on complicated. (*) most serious users of CAS software i know (maple, etc.) always type their code in a window using a standard editor, and copy-paste it in another window running maple, maxima, etc. Using the GUI toolkits is almost always a considerable loss of time. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD needs fresh Blood!
Warren Block writes: It continues to amaze me how much you have in there. Oh, and my times earlier were probably user time rather than wall time, for which I'll shiftily blame the difference between csh's time builtin and /usr/bin/time. Redoing that: portmaster -L | filterfu: 43.6 pkg_version -vl'':30.5 portversion -vl'': 3.6 portmaster -L --index-only: 2.5 I don't have the same experience by far: on a jail i have: . === 68 total installed ports === 61 have new versions available portmaster -L --index-only 0.76s user 1.65s system 6% cpu 38.871 total So it takes 38s on a *very small* installation. My experience is that all FreeBSD ports tools are incredibly slow, be it portupgrade, portmaster, even the basic tools like pkg_version. Maybe it would help to recognize that such observations are perhaps not unrelated to the original poster comments. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Find a corrupt port
Doug Barton wrote: The problem with this is that dependencies are actually recorded as a pair. For example: @pkgdep pkg-config-0.25_1 @comment DEPORIGIN:devel/pkg-config Someone else already was kind enough to mention 'portmaster --check-depends' which will prompt you to do the right thing and/or notify you about ports that you need to reinstall. Or if you like something more automated, faster, and giving more information, you can run: http://www.lpthe.jussieu.fr/~talon/check_pkg.py -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Debian GNU/kFreeBSD
Michal Varga wrote: On Sat, 2011-02-12 at 23:33 +0330, Bahman Kahinpour wrote: Does anyone think that having an optional APT system somewhere like in the Ports Collection or ... You already know where the ... is, it's called Debian GNU/kFreeBSD. I have been told that both its users are perfectly happy with apt-system and everything else that accompanies it and then for the rest, there's this other thing called FreeBSD. This other thing that you mention has two components, the kernel and basic utilities, managed by very competent people, and the ports which covers more than 20 000 various software and gives flesh to the system. One may very well be reasonably happy with the first component (hardware support is not always first class, notably for laptops) and be disappointed by the second component. It may be that Debian/kFreeBSD will succeed in associating a good kernel to a good userland, depending on the care offered by the Debian people to this project. I don't think that grafting apt on the ports system would work as well as in Debian. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: i keep *trying* to move from portupgrade to portmaster
Doug Barton wrote: On 08/06/2010 15:03, Adam Vande More wrote: While your in the mood for for taking portmaster suggestions, I am always in the mood for taking suggestions. :) I think an option to backup all currently installed packages would be useful. for pkg in /var/db/pkg/* ; do pkg_create -b $pkg done I have a python script that does this for me, but it would be easy enough to use sh as well. I do this because there have been too many times something has broken during a port upgrade run I don't think pkg_create preserves the config files user edited, which is the precious stuff, but it preserves a lot of useless stuff. The following python script by Cyrille Szymanski may be more useful: http://www.lpthe.jussieu.fr/~talon/pkg_save.py It keeps the config files and the shared libraries. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Portmaster with package support ready for beta testing
On Tue, Nov 10, 2009 at 11:46:17PM +0100, Dominic Fandrey wrote: If you want to work without a ports tree use pkg_upgrade (sysutils/bsdadminscripts), it only requires an INDEX file. The next version will also require the MOVED file (as is now provided by Pointyhead). Very nice, your program is in the same spirit as my own: http://www.lpthe.jussieu.fr/~talon/pkgupgrade except written in shell, which is quite a feat! Since python is easier to manage, pkgupgrade follows MOVED and tries to be fast. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Portmaster with package support ready for beta testing
On Mon, Nov 09, 2009 at 12:05:45PM +0100, Miroslav Lachman wrote: Does it mean that one needs ports tree or provide custom INDEX in case of custom packages with non default options (different dependencies) to compute order od dependencies? (AFAIK plain pkg_add works without ports tree and INDEX, that's why I am asking) This is because a package contains a list of requirements. However problems may appear, for example if requirements have changed between the installation of the ports you have on your machine and the moment when the package has been compiled. Moreover some ports compile different stuff according to what is present on your machine. The configure script may autodetect stuff like gnome, etc. and automatically compile for example a gnome version of the program. For all these reasons there may be divergences between the dependencies as seen on your machine and the ones recorded in the package which has been compiled elsewhere. It is related to my idea of extending packages with more metadata, for example OS version + arch, used build options (WITH_ / WITHOUT_ etc.) so one can easily determine how this package was built. But it seems as not so easy task to me, as I don't know how to get all the options (from /etc/make.conf, environment variables, /var/db/ports, commandline...) and record them to file in useful way. It can be useful in case where I have some backup of packages from many machines, but have not the original environment, where packages were built etc. For the above reasons i think that using precompiled packages should be restricted to people who don't mess with the standard settings. When you install some Debian packages you take them as is, and things generally work because mostly everybody use the same packages which are well tested and coherent. If, on your machine, you want to use a specially configured program, you download the sources and compile it. But you take care yourself of the upgrades of this program. I think that a similar behaviour should be viable on FreeBSD. If you extensively modify the configuration of a large number of ports, you cannot expect a packages-based upgrade to work. In this case the only reasonable way is to upgrade from source. Miroslav Lachman -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Portmaster with package support ready for beta testing
Miroslav Lachman wrote: I take a quick look at the code and I have one question. Can you explain way --no-deps and --force are used for pkg_add? I can only venture an explanation. Once you have computed a good order for upgrading via packages, you cannot accept that pkg_add ruins your computation by doing things on its own. In principle you have a global view of the problem, which is better than the local view embedded in each package. Hence forcing pkg_add is the only sane way. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Lighttpd: (mod_fastcgi.c.1742) connect failed
O. Hartmann wrote: 2009-09-03 19:47:49: (mod_fastcgi.c.1742) connect failed: Connection refused on unix:/tmp/lighttpd-fastcgi-php.socket-7 Have you checked the permissions? I seem to remember i had the same problem once with lighttpd and it was because permissions of the socket under /tmp. Now my server works OK since ages. I had to take provisions for permissions in the fastcgi python responder. In my case the relevant bits are when daemonizing the responder: pid = os.fork() if pid 0 :# In first child import time time.sleep(3) while not os.access(socket, os.F_OK) : time.sleep(1) # the socket created by the child is made accessible to the web # server os.chown(socket, wwwuid, wwwgid) os.chmod(socket, 0700) sys.exit(0) # Exit first child While still being root i adjust the permissions of the socket. Then i change effective userid: . # And finally the routine which starts the fcgi responder, as user www os.seteuid(wwwuid) WSGIServer(request_handler, **wsgi_opts).run() The complete script you can get at: http://www.lpthe.jussieu.fr/~talon/show_index.fcgi It is a simpler server than for example django if you want to understand fastcgi. By the way the aim is to display the FreeBSD ports trough a fastcgi responder. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADUP] FreeBSD Gecko's TODO and plan for future
Andrew Reilly wrote: I've stopped using portupgrade in favour of portmaster, but I don't see a ready equivalent to this with portmaster, hence my dumb script. In particular, I don't think that portmaster can combine the -r and -x flags (depend and exclude), and when I've done -f -r in combination before, then it seems to build the entire transitive closure of dependencies, rather than just the immediate ones. Hence my question about a tool to manipulate the dependency graph as a graph... You can always play with http://www.lpthe.jussieu.fr/~talon/pkgupgrade which, i think, is a lot easier to hack than portupgrade, and includes, like portupgrade, a dependency graph computation. Beware that there is not a unique way to compute the upgrade order, so you cannot be sure to get an optimal way. In a few words, the problem is to get a total order on a set of ports compatible with a partial order given by dependency. There is always such a total order, but it is not unique. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [Call For Testing] VirtualBox for FreeBSD! take2
Martin Wilke wrote: Next run, We updated the port to 2.2.2r19801. Works for me fine on a FreeBSD-7.1 machine running i386. I am running just now a FreeBSD-8 snapshot. But the NetBSD-5 iso crashed the virtual machine. Nice work Thanks. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mtools vs X11 (Re: FreeBSD Port: syslinux-3.72)
Steven Kreuzer wrote: Personally, I think it makes more sense for mtools to be the full and complete representation of the actual program. Personnally i think that such opinion considerably harms the ports system, by transforming some ports (fortunately not many) into a kitchen sink of dependencies, which cause considerable trouble for the unhappy users. Adding X, which is a very big dependency for a port like mtools, where nobody in his right mind would think or even know there is a guy, is like adding the whole TeTex for getting the symbol font (i have seen that) or other similar wise decisions. If a little judgement was applied in such cases, it would enhance greatly the usefulness of the ports system. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mtools vs X11 (Re: FreeBSD Port: syslinux-3.72)
Steven Kreuzer wrote: Can we consider people who use the CLI an advanced user? If so, the expectation that they will be able to build a port with -DWITHOUT_X11 is not unreasonable. People who are more likely to use the GUI are the ones who will not be aware of the WITHOUT_X11 knob. And the end user who uses prepackaged packages will get mtools with a totally useless GUI. I have hard time beleiving you are not trolling with such theories. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: installed ports dependency tree?
Doug Barton wrote: Robert Huff wrote: Suppose I have installed ports A..Z. Some of these are standakone; some depend on others on the list; others depend on installed ports not on the list. Is there a port that will produce a unified and ordered dependency list, such that upgrading/reinstalling in that order will avoid multiple rebuilds? Not sure what you mean about avoiding multiple rebuilds, unless you're talking about generating a list and installing all the ports on that list one at a time. The installed ports form a dependency tree which is hopefully a direct acyclic graph (DAG). When there are cycles it is supposed to be a bug in the system. For a DAG you can always order the elements in such a way that this total order is compatible with the partial order given by the DAG. I don't remember if portmaster does that, but i am sure that portupgrade does it, an so does my pkgupgrade. Using such an order (it is not unique) one can guarantee that (barring bugs in the ports system) one can remove packages without breaking other packages or install without doing multiple rebuilds. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Scilab 5.0
bf wrote: Yes, I hope to soon, but I am busy at the moment. I'd be interested in hearing whether users of the existing scilab 4.x port would like the new version, which is Java-based, to replace the old port -- or just be added in addition to it. If the new Scilab Java interface is as bad as the new Maple Java interface, maybe it is wise to keep the old Scilab 4.x in the ports tree ... -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Scilab 5.0
To add to : If the new Scilab Java interface is as bad as the new Maple Java.. I have just tried the new scilab under Ubuntu, the help screen is next to unreadable, due to far too small fonts, and no configuration possibility, worse the plots core dump. So keeping scilab-4 in the ports seems useful. Otherwise the main window seems fine. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: numerous gcc installations
Nikolaj Thygesen wrote: Could anyone please explain to me whether it's really required to have two extra versions of gcc installed. I Recently upgraded py25-numpy, which in turn pulled in gcc-4.2.5_20081126 as a dependency. A few days ago blas refused to compile because: This occurred to me recently. Fortunately you can find precompiled blas, scipy and numpy (pkg_add -r py-numpy works). But i was out of luck with matplotlib, which required pkg_adding gcc-42 and then compiling tons of stuff. One of them (agg, i think, requires DISPLAY to be set and accessible in the configure script !!!) hence breaks the build for matplotlib. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
DragonFlyBSD mail agent
Hello, would it not be interesting to have the DragonFlyBSD mail agent in FreeBSD? It is a very simple mail agent, like ssmtp, but with some more features: it can either deliver mail locally for local users or send all other mail to a smarthost, and reads the aliases file. Hence it fulfills the needs of the person who wants a small mail agent for receiving periodic root mail, and wants to send the occasional without too much fuss. It is much simpler than sendmail, postfix or exim. For simplicity i have a tarball here: http://www.lpthe.jussieu.fr/~talon/dma.tgz it compiles out of the box, and it is easy to figure out how to use it. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: DragonFlyBSD mail agent
Janky Jay, III wrote: By default, FreeBSD's Sendmail that comes in base already delivers mail to local users and reads the aliases file also. It supports configuring a smarthost as well. Unless there are some highly desired features in the DragonFlyBSD mail agent, I seriously doubt there will be any migration to it from Sendmail in the near future. I was not speaking of replacing sendmail in the base system, only on offering this mail agent in the *ports*, this is why i posted in freebsd-ports. I should have been clearer. This mail agent doesn't offer anything compelling compared to sendmail, only it is much smaller and presumably more secure. For example if you want a mail agent in a jail, you can envision to use this one instead of sendmail because it is much lighter. Yes i know ssmtpd could do the same, more or less but this one has a little more flexibility without falling in the complexity of the big ones. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: DragonFlyBSD mail agent
Le jeudi 08 janvier 2009, vous avez écrit : On Thu, Jan 08, 2009 at 05:48:10PM +0100, Michel Talon wrote: This mail agent doesn't offer anything compelling compared to sendmail, only it is much smaller and presumably more secure. I have previously seen it advocated for base as an alternative for systems that e.g. only need to send cronmail. mcl I am using DragonFly mail agent on some jails since a few months and it works OK. Hence dma.tgz compiles out of the box and works as advertised on FreeBSD. I can give some information on the configuration: this shows the simplicity of the configuration file. jail1% cat /etc/dma/dma.conf # $DragonFly: src/etc/dma/dma.conf,v 1.2 2008-02-04 10:11:41 matthias Exp $ # # Your smarthost (also called relayhost). Leave blank if you don't want # smarthost support. Here i take the base host as smarthost SMARTHOST niobe # Use this SMTP port. Most users will be fine with the default (25) PORT 25 # Path to your alias file. Note it reads aliases, not aliases.db. Same file # as sendmail aliases. ALIASES /etc/mail/aliases # Path to your spooldir. Just stay with the default. SPOOLDIR /var/spool/dma # Path to your virtual user file. Just stay with the default. VIRTPATH /etc/dma/virtusertable To deliver local mail it seems that dma needs to be suid root: jail1% ls -l /usr/libexec/sendmail/dma -r-sr-sr-x 1 root mail 42904 Aug 20 00:45 /usr/libexec/sendmail/dma The spool directory is drwxrwxr-x 2 root mail2 Jan 8 03:05 dma ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Latex port
Xihong Yin wrote:
I installed teTeX from port, but I found that I have no 'table'
environment. Can anybody tell me what's wrong?
Works perfectly fine for me:
Compiling the following under teTeX and FreeBSD-7 works and gives the
expected result:
\documentclass{article}
\begin{document}
\begin{table}[ht]
\centerline{
\begin{tabular}{|l|c|c|}
\hline
colonne 1 colonne 2 colonne 3 \\
\hline
1.1 1.2 1.3 \\
2.1 2.2 2.3 \\
\hline
\end{tabular}
}
\caption{\label{mylabel} Title}
\end{table}
\end{document}
niobe% latex toto
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(./toto.tex
LaTeX2e 2003/12/01
Babel v3.8d and hyphenation patterns for american, french, german,
ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch,
esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar,
norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish,
swedish, tur
kish, ukrainian, nohyphenation, loaded.
(/usr/local/share/texmf-dist/tex/latex/base/article.cls
Document Class: article 2004/02/16 v1.4f Standard LaTeX document class
(/usr/local/share/texmf-dist/tex/latex/base/size10.clo)) (./toto.aux)
[1]
(./toto.aux) )
Output written on toto.dvi (1 page, 624 bytes).
Transcript written on toto.log.
niobe% ls /var/db/pkg|grep teTeX
teTeX-3.0_1/
teTeX-base-3.0_6/
teTeX-texmf-3.0_3/
--
Michel TALON
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: TeXLive
Romain Tartière wrote: Well, I don't think of importing TeXLive into the FreeBSD ports tree as a replacement of teTeX (sorry if that was unclear by what I meant by drop-in replacement). I was just thinking about having both in the ports tree, leaving existing dependencies untouched so that ports that used to depend on teTeX still depend on it... TeXLive would only be installed if the user explicitly want TeXLive instead of teTeX. I concur with that, as a TeX user since many years. For me teTeX is already overbloated as far as possible, particularly when some unconscious maintainer adds dependencies like cm-super which are perfectly non necessary, please don't impose on us abominations like TeXLive, leave that optional. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: print/cm-super size mismatch
Stephen Montgomery-Smith wrote: I had this problem yesterday, when it was fixed last week. My guess is that that the bug is not still there but that it was renewed. I am thinking that distfile was updated yet again. By the way, does someone knows why cm-super is listed as a dependency of print/teTeX while it is obviously *not* necessary to run teTeX and is a very big download? Notably since there exist other conversions of the Computer Modern fonts to Type1 requiring infinitely less space than cm-super, for example: http://www.ctan.org/tex-archive/fonts/ps-type1/cm-lgc/ -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: multimedia/xvid
On Fri, Oct 10, 2008 at 10:11:35PM -0300, Carlos A. M. dos Santos wrote: Standard questions: 1. O which architectures did you test this? On a P4 HTT. I can test that on an Athlon T Bird and a Core 2 Duo in 386 mode, but i don't have access to an amd64 machine running FreeBSD, and of course other architectures. The assembly files in question contain MMX,SSE and SSE2 instructions so apply only to such processors. 2. Did you send a PR? No 3. The port currently has no maintainer. Would you like to take it? :-) I have no problem taking it, on the other hand the required modification is minimal. I have checked on the xvid site that there is no more recent version. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: multimedia/xvid
On Sun, Oct 12, 2008 at 12:42:08AM +1100, Sean Winn wrote: Another option is to just fix the configure script so it doesn't break on nasm 1 (it's failing on the patch level check) The attached file dropped in ports/multimedia/xvid/files/ seems to do the trick, though I don't use xvid so I can't exactly test that the new version assembles things properly. Something done to configure.in should be sent upstream really. Yes, fixing the configure script should be done upstream, but it seems that the xvid project is somewhat asleep, so better use yasm in the Makefile on which there is control. As you note below, the problem comes because the configure script tries to use the -r option which yasm has but not nasm, so the xvid people had really yasm in view when doing their work. --- configure.orig2008-10-11 13:40:34.0 +1100 +++ configure 2008-10-11 13:43:14.0 +1100 @@ -4016,7 +4016,12 @@ if test $ac_nasm = yes ; then echo $as_me:$LINENO: checking for nasm patch version 5 echo $ECHO_N checking for nasm patch version... $ECHO_C 6 - nasm_patch=`$nasm_prog -r | cut -d '.' -f 3 | cut -d ' ' -f 1` +nasm_version=`$nasm_prog -v | cut -d '.' -f 1 | cut -d ' ' -f3` +if test -n $nasm_version -a $nasm_version -gt 1; then + nasm_patch=$minimum_nasm_patch_version +else + nasm_patch=`$nasm_prog -r | cut -d '.' -f 3 | cut -d ' ' -f 1` +fi if test -z $nasm_patch ; then nasm_patch=-1 fi By the way, the performance improvement obtained by using SSE instructions in the assembly files is astounding. I could not beleive what i was seeing, basically an x 4 improvement, that is the code perfectly parallelizes the computations on the 128 bits registers. This is a good illustration of the fact that compilers are not always as smart as people say, and assembly code can crush C code. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Found CONFLICTS: ...
On Mon, Oct 06, 2008 at 02:17:43AM +0400, Boris Samorodov wrote: Michel Talon [EMAIL PROTECTED] writes: I think that CONFLICTS is a cure with worse effects than the disease. Well, then you may cut off this cure by defining DISABLE_CONFLICTS. This is indeed the solution i came to in: http://www.lpthe.jussieu.fr/~talon/freebsdports.html -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Found CONFLICTS: ...
Jan Henrik Sylvester wrote: Should all CONFLICTS be documented? I think CONFLICTS should be treated by ignoring them completely. They cause no end of troubles in Debian, for very little if any usefulness. What is the problem if you install texi2dvi one way or another? -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Found CONFLICTS: ...
On Sun, Oct 05, 2008 at 04:24:46PM -0500, Scot Hetzel wrote: On Sun, Oct 5, 2008 at 3:25 PM, Michel Talon [EMAIL PROTECTED] wrote: Jan Henrik Sylvester wrote: Should all CONFLICTS be documented? I think CONFLICTS should be treated by ignoring them completely. They cause no end of troubles in Debian, for very little if any usefulness. What is the problem if you install texi2dvi one way or another? There are several problems: 1. These two texi2dvi programs might have a different set of arguments, that other programs rely on. 2. When upgrading the ports, which port is the one that installed texi2dvi, as the last port upgraded has it's texi2dvi installed. 3. When removing either teTeX-base-3.0_14 or texinfo-4.11, it has the unwanted side effect of also removing /usr/local/bin/texi2dvi from the system, which may affect the operation of one of the other programs that relies on texi2dvi. These same problems also applies to libraries, config files, man pages, and other documentation. Scot Of course, but all these problems are far less annoying than the problems coming from overzealous CONFLICTS notifications, which can completely ruin your mental health. After all, if some program goes astray after having removed some apparently unrelated port, the simple solution is to reinstall this program, and its dependencies. Problem is almost a non problem. Of course the good solution is that ports developers try to avoid conflicts by choosing appropriate names, but in general this would require considerable work, or install everything in its own directory and use symlinks in public directories (/usr/local/bin,etc.) like Debian does, which promptly creates a terrible mess. I think that CONFLICTS is a cure with worse effects than the disease. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My interactive version of pkg_add - finished!
Marin Atanasov wrote: Should I add something else to it or modify something? You should remove a lot, because many implicit rules are already defined in /usr/share/mk/sys.mk which is sourced by make automatically. See for example /usr/src/usr.sbin/pkg_install/add/Makefile to discover how little is needed. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My interactive version of pkg_add
Marcin Wisnicki wrote: Unless I'm missing something there needs to be a MOVED file or ideally something like it that has pkgnames (with versions) for a binary package update tool to work. First, congratulations to Marin Atanasov for having completed his program! As far as i understand, Marin's goal was simpler that an upgrade tool for binary packages, it was simply an install tool, allowing to choose interactively on various repositories. I think this goal is fulfilled and is useful. For upgrading, the situation is vastly more complicated, indeed one needs to read MOVED and use information here, in particular follow the name changes of ports. For example you may have a port whose proper upgrade has a different name, etc. or ports have disappeared, etc. I am not even sure that a completely bullet proof system can be written within the limits of the present FreeBSD ports system. I am quite sure that one of the keys of Marcin's success is having limited his aims. Similarly the excellent portmaster tool for upgrading owes its success to strict limitation to upgrade from source, using the available preexisting pkg_* tools - plus a lot of polishing. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My interactive version of pkg_add
Marin Atanasov wrote: So what do you think - is it worth improving upon it or it's a waste of time? Thanks for any suggestions. I think it is worth improving and certainly not a waste of time. Each work which allows to use precompiled packages more efficiently in FreeBSD is very useful, in my opinion. While compiling ports is very fine on a server, where only a small number of ports are installed - and then the tool portmaster does that really wonderfully, looking at the other extreme, a desktop with around a thousand installed ports is better managed through precompiled packages. And, sorry, but portupgrade is not the solution to do that, either with the -P or -PP option. I can only concur with the suggestion you mention, exploring ftp sites to discover what is available here. How to do that efficiently is harder. Apparently official FreeBSD ftp sites have an INDEX of available packages. I hope it is reliable. Then i suggest to download it and work from that. Best regards -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Exploring the FreeBSD ports tree
Hello, while playing with fastcgi stuff, i have updated my tool to explore the FreeBSD ports tree. It is now a fastcgi responder which can answer questions behind a web server such as apache or lighttpd. It can be found here: http://www.lpthe.jussieu.fr/~talon/show_index.fcgi The needed configuration for lighttpd is explained in the comments at the beginning, this is basically the same as for Django. So one needs to run the python script show_index.fcgi as root, it creates a socket in /tmp, daemonizes, and changes its ownership to www. It then communicates with the web server through this socket. To browse the ports tree, just point the browser at /showindex/ on the given server. A reasonable number of queries per second is achievable through this setup. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: firefox 3 causing xorg to suck up all available CPU
Alex Dupre wrote: gamin is completely broken and can enters infinite loops. Switch to fam. I would say exactly the opposite. I had enormous problems when KDE was using fam, particularly with NFS mounted home. In fact fam sucked all NFS server bandwith. This problem was completely solved by the switch to gamin. For me gamin works perfectly OK. By the way i have seen Firefox3 sucking all the X processing power (to the point the display was almost completely frozen), return to the normal being obtained when killing firefox. I have seen that only on some specific web pages, but it was completely reproducible on these web pages. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for comments - pkg_trans
Ivan Voras wrote: I apologize in advance if what I'm trying to do seems stupid or it has=20 already existed since the Dawn of Time (i.e. when McKusick was in=20 diapers) but I'd like your comments on this idea: http://wiki.freebsd.org/IvanVoras/PkgTransProposal I can write the pkg_trans utility and modify the C utilities (pkg_add,=20 pkg_delete, if they're sane) but I can't do makefiles and ruby, so if=20 this is to work, I'll need some help :) I find this idea fantastic! This is much needed in the FreeBSD ports system. In fact without such a mechanism, it is difficult to have a reasonably good upgrade system. For example suppose you install KDE, and as a dependency some software is installed. In a new version of KDE this software has been abandoned and replaced by more modern stuff (example fam - gamin). If both still exist in the ports system, without your mechanism, both will be upgraded regularly. Keeping state on things which have been installed as dependencies and thus can be removed if the dependency is no more present is necessary. Of course it is also a convenience for the end user. As to the necessary modifications in portupgrade, perhaps not a lot if the basic tools (pkg_add, etc.) work correctly by themselves, since portupgrade mainly calls these tools. But of course, injecting the above state information in pkgdb.db would perhaps be useful. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for comments - pkg_trans
Doug Barton wrote: BTW, I thought of another problem scenario. The user installs port M, and it brings dependencies D1, D2, and D3. Then the user installs port N which also has port D2 as a dependency. Then D2 becomes available for deletion only after M and N have been deleted or no more require it. I don't see a big problem here. Perhaps it is however a problem for the notion of transaction, since a group of ports flagged for deletion by a transaction cannot be entirely removed after some time when part of it is needed by other ports. This means one needs to keep a very complete and detailed data basis of the operations, of course. By the way, on the course of time, ports belonging on a transaction are upgraded, may change name (according to the MOVED file) so one also have to continually update this information in the data basis. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Upgrading through packages: an experience.
Hello, Since KDE recently appeared in the Latest prebuilt packages, and my main desktop ports (running FreeBSD-7.0-RELEASE) had not been upgraded since more than a year i decided to test my pkgupgrade (www.lpthe.jussieu.fr/~talon/pkgupgrade) on a machine with many ports installed (all Gnome and KDE basically, plus many other things) and going through several important changes in the ports system (the new modularized Xorg, the new gettext, etc.). I wanted a worst case test, including using the Latest packages and not a RELEASE. The net result is that it went through without problems, at a speed comparable to that one observes for Debian upgrades, but at the end some small glitches remained, due to using Latest packages. Some details follow: -first the script pkgupgrade crashed. This is due to the fact that the old python version used libpthread, and there are apparent bugs on 7.0, while it worked OK on 6.2. This was solved using libmap.conf to force use of libthr for threading. Since KSE is now deprecated it is not useful to describe this bug more fully. Anyways programs doing IO and threading don't act reliably with libpthread under 7.0. - after that things were smooth. There has been fantastic progress in the utility pkg_add, it runs at least twice faster than last year. This explains the very speedy upgrade i had. More precisely, first the specs of the machine, it is a 4 years old Pentium 4 with IDE disk, so nothing particularly fast. There were 744 installed ports initially. Some of them i put on hold, since they are very heavy to build or install (java, tetex). So finally pkgupgrade removed 616 old packages and installed 877 new packages (the difference is of course because of the new modular Xorg). A few remained to be compiled. At the end i have now 1017 installed ports. - the speed of this upgrade was really remarkable. The initial analysis by pkgupgrade took 2 min, the download of necessary packages (for a total of 1.3 GB) from the french FreeBSD mirror took 5 min (i have a 100Mb/s connection to it, but this also shows the gains of maintaining a unique ftp connection to the server for the whole download), and was simultaneous with backing up the old packages (only shared libraries and config files) which took 28 mn. So after half an hour i had a shell script that i reviewed fully to avoid removing stuff that i had forgotten to put on hold. - then i runned the shell script UpgradeShell, which removed old packages (took 18 mn, pkg_delete is still slow, compared to pkg_add) then installed 877 packages in 48 mn! This is absolutely fantastic, last year i spent here 2 hours in a much smaller installation. Finally it compiled a few packages, notably one of them kdewebdev took 2 hours by itself, that is much more than the complete upgrade procedure. This illustrates the point that compiling from source is a waste of time. I have put the Logs here http://www.lpthe.jussieu.fr/~talon/2008-07-11.tgz so that one can see how it runs in practice. Now the problems. They come from the fact that the Latest packages are not always coherent between themselves or with the libraries in FreeBSD-7.0. So, while most programs runned perfectly well, a few crashed when i tried them. I traced most problems to the fact that the use of fcntl() to lock files did not work in some cases. This was for example the case for tin when it tries to lock the posted file. I had to recompile such ports, now they run fine. An example which doesn't run is kdm because it needs to lock /var/run/kdm.lock. This is very annoying since kdebase is huge to recompile. All other KDE stuff runs OK. The lesson of this story is that it is *not* a good idea to use the Latest packages when doing binary upgrades, one should stick to RELEASE. Conclusion: binary upgrades, even in very messy situation are very doable. They take a reasonable time, completely comparable to what one may expect under Linux. Compiling a single KDE port took longer that the whole upgrade procedure except the compilation. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading through packages: an experience.
On Sat, Jul 12, 2008 at 04:35:29PM +0200, Kris Kennaway wrote: Michel Talon wrote: Hello, Since KDE recently appeared in the Latest prebuilt packages Well, it's always been there, except when it could not be built. Well it was not here ten days ago, i think, when it was discussed in this mailing list. I checked, this days and several days afterwards. Then i saw since perhaps 2 or 3 days. Now the problems. They come from the fact that the Latest packages are not always coherent between themselves or with the libraries in FreeBSD-7.0. No, they are. In fact this is a key design feature, and the same reason why sometimes certain packages do not appear on the FTP site (if they did appear they would be necessarily *out* of sync). Similarly they are always built against recent versions of -STABLE, by design. So there has been some changes between 7.0-RELEASE and STABLE since i have just got some minutes ago: niobe% wget http://myfreebsd.homeunix.net/csup.core /libexec/ld-elf.so.1: /lib/libc.so.7: version FBSD_1.1 required by wget not found I did not remember that versioned symbols were in FreeBSD-7. Of course after a rebuild, wget works. I had another similar problem somewhere, but all others were related to fcntl() locking (*) problems. Glad to hear your experience was generally positive though. Yes, very positive. In particular a point i forgot to stress, the coverage of the prebuilt packages is excellent now, as can be testified by the fact that only 19 ports had to be compiled while 877 packages were present. This is thanks to you and your work on the cluster. One aim of my message was to show that, at present, the coverage is so good that one can envision a Debian-like experience on FreeBSD when doing binary upgrades, even going through considerable evolutions. Kris (*) This is a ktrace of the problem: niobe# ktrace -di kdm-bin . 4214 kdm-bin CALL open(0x283052c4,O_RDWR,unused0xe) 4214 kdm-bin NAMI /var/run/kdm.pid 4214 kdm-bin RET open 3 4214 kdm-bin CALL getdtablesize 4214 kdm-bin RET getdtablesize 11095/0x2b57 4214 kdm-bin CALL fcntl(0x3,F_GETFL,0) 4214 kdm-bin RET fcntl 2 4214 kdm-bin CALL fstat(0x3,0xbfbfddb0) 4214 kdm-bin RET fstat 0 4214 kdm-bin CALL read(0x3,0x28314000,0x1000) 4214 kdm-bin GIO fd 3 read 0 bytes 4214 kdm-bin RET read 0 4214 kdm-bin CALL lseek(0x3,0,SEEK_SET,0) 4214 kdm-bin RET lseek 0 4214 kdm-bin CALL fcntl(0x3,invalid=12,0xbfbfe730) 4214 kdm-bin RET fcntl -1 errno 22 Invalid argument Note the invalid=12. This is followed by: 4214 kdm-bin CALL sendto(0x4,0xbfbfd46e,0x4e,0,0,0) 4214 kdm-bin GIO fd 4 wrote 78 bytes 27Jul 12 17:18:29 kdm-bin[4214]: Can't create/lock pid file /var/run/kdm.pid And here the kdm.pid is created, it is the locking which fails. Clearly things have changed for the fcntl() action type between FreeBSD-7.0-RELEASE and the machine on which kdm-bin has been compiled. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] pkg_delete(1) speedup
Roman Divacky wrote: To my eye, it doesn't look like matchbyorigin() could be re-implemented to be faster with little effort, but could somebody have a quick look as well? Would doing mmap() instead of scanning file line-by-line be any faster? (though I'm not saying it's a great idea) In the python script check_pkg.py that i mentioned previously (*), i observed that implementing a mmap solution insted of working line by line produced a *great* speedup (5 times if i remember well), but perhaps this is due to python specifics. (*) http://www.lpthe.jussieu.fr/~talon/pkg_check.py -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports system woes
Garrett Cooper wrote: We're rehashing the discussion made last year around June - July. Indeed. We came to the conclusion that BDB should be used, as no other DB backend / API exists in the base system (currently), and porting SQLLite (while nice) appeared to be non-trivial to port Are you kidding? The patch files are totally trivial modifications, to include stdlib.h. The bigger one is in Makefile.in to take into account these ones. and got a lot of unhappy responses from folks. This is true. A lot of people expressed aversion against SQL, by itself. However it should not be bad to evaluate a solution based on BerkeleyDB, another one on sqlite, and chose based on merit, not on aversions. What is the simplest to use by the programmer writing pkg_* tools, what offers the best performance and data organization, etc. At the moment portupgrade uses a BerkeleyDB, are you convinced by the result? In particular an obvious fact is that there are constant troubles when the DB version number changes or the ruby adapter changes. One may expect that no such problems will occur with a very stable and standardized language like it is offered by sqlite. If this argument is correct, it is quite strong, in my opinion, because i don't expect much performance difference otherwise. There is also the question of atomicity and locking which is particularly important in this context. It would be useful to compare what the BdB in the base system has to offer compared to sqlite - because comparing to what the most recent versions of bdb in the ports can do has a different bearing on the question. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports system woes
Pav Lucistnik wrote: Quick solution would be to gather all depnames for the deleted package, and then do a single pass over /var/db/pkg entries looking for origins. Ultimate solution would be to implement a database which would concentrate origins for all packages with linear lookup time. In fact last year i wrote a python script which reads all the /var/db/pkg/+CONTENTS files, and fixes all the +REQUIRED_BY files, assuming they are corrupted. Moreover it follows the MOVED file. Optionnally it decomposes the set of ports in connected components, and builds graphviz graphs for the dependencies. Of course the leaf packages are written down. As far as i remember this program runs in a few *seconds* certainly not minutes like it is said here for the pkg_delete stuff. You can find it here: http://www.lpthe.jussieu.fr/~talon/pkg_check.py This being said, i agree with you, that for various reasons, the package system needs to get rid of the extremely bad idea of abusing the filesystem as a database, and use a true database for doing its job. This would allow O(1) searches, as you are saying, and would allow to perform appropriate locking for supporting parallel builds. We had this discussion last year, and i am even more convinced that the good solution is to use sqlite and not some half-assed solution like a Berkeley database, if only because using a sql database will lead naturally to a more structured solution, and not a pile of blobs, and also because sqlite is a stable software. More generally i disagree with Kris Kennaway idea that all is required is to polish the existing tools. They are so obviously broken from all points of view, particularly portupgrade, that only a complete rewrite can do any good. Needless to say, this cannot please those FreeBSD ports afficionados who are convinced that their toy is the best in the world. Let me recall that *one* person has completely rewritten the ports system for OpenBSD (Marc Espie), including the pkg* tools and all the Makefile scripts, and now it works. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports system woes
Frank Mayhar wrote: Portupgrade is, in fact, my preferred application, although lately I've had to move to portmaster just because of the O(n^2) inefficiencies. It doesn't need to be replaced, it needs to be fixed, I have rarely seen such a wonderful contradiction between the two halves of the same sentence. Oh, please. The FreeBSD ports system works as well. Instead of No, it doesn't or it does barely. complaining, why don't you actually do someting about it? Code speaks louder than mere words. We have learnt recently that many people have brought code to the table, including myself, only to be scorned by people of your sort. I have yet to see people like you contributing any testing or discussion when code is offered, all you are good for is parrotting Code speaks louder than mere words. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Utility for safe updating of ports in base system
On Thu, Mar 20, 2008 at 01:05:27AM -0700, Doug Barton wrote: On Thu, 20 Mar 2008, Michel Talon wrote: Doug Barton wrote: i would venture to say that such an utility should be able to upgrade things based of *binary* packages, and consequently that portmaster is not a suitable candidate. That ability is not included in the current requirements document, and was not specifically mentioned the last time we had the discussion on the list. If the portmgr folks intend that to be a requirement, the current ideas list entry should be amended. Indeed you are right, but i think this should be a requirement for the reasons discussed below, and is implicit in the fact that the projects refers to a portupgrade written in C, and portupgrade has such a feature. For example pkg_add installs a binary package, if you want to compile and install you run make all install clean in the ports tree. Um, you lost me there. This is simple, all pkg_* tools operate on binary packages at present, it would be strange that a newcomer, pkg_upgrade has no way to operate on binary packages. One of the requirements of an upgrade system is predictability, this can only be achieved by using binary packages. You gain a certain amount of flexibility with packages, at the expense of being able to customize things. As long as the user understands that, then it's fine. I agree that the possibility of compiling from source brings ability to costumize things. However this very ability ruins all hope of having a smooth upgrade system. Due to customization, as soon as you have many ports installed, there is a combinatorial explosion of possibilities and nobody can test that the upgrade process works. OpenBSD people have been converted to this idea, and now push for an upgrade from binary packages exclusively. So i think that the user should have two possibilities: - either he wants to customize, and he is on his own. He will need to compile his software, and in this case portmaster is the perfect tool for managing his upgrades. Since the compilation will take most of the time, it is not relevant to consider performance questions on the portmaster side. - or he wants to use a tried and true upgrade path, he doesn't want to spend time compiling, he wants speed. Basically he wants the Debian or Ubuntu experience. In this case, using prebuilt binary packages is the only reasonable way of achieving the result. I agree that due to licence peculiarities (think e.g. Java) there are a small number of ports which will need compilation, so the experience cannot be perfect. Another requirement, in my opinion, is speed, and the lack of speed, which is completely hidden when you compile your packages will be immediately apparent if you try to use packages. Indeed portupgrade has options -P and -PP to work with packages which could serve as a prototype for a pkg_upgrade written in C, except that they work poorly, and in particular run slowly. Where do you think the slowness is? Several causes of slowness have already been identified. Parsing /var/db/pkg is slow, this is why the idea of using a database has been advocated. Much worse, running make in a port directory, even only to get the value of a variable is slow. Programs like portupgrade do such things repeatedly without caching the results in memory and incur large time penalties. Similarly for each package he wants to download, portupgrade opens an ftp connection and retreives it independently, etc. Obviously no effort at all has been spent so that things are fast. One of its features, that i consider very important for correct operation, is that it computes the list of all packages to be deleted and all packages to be installed and asks the user if he agrees before doing anything. Why do you consider this an important feature? (I'm not disagreeing, just curious about your thought process here.) Because you can see that something is going to break in advance and renounce to the upgrade. This occurred several times for me on Debian. Usually this is because some package has a security problem, and this is solved waiting one or two days. It fetches all necessary packages before installing or deleting anything. That seems sensible, thanks for mentioning that bit. Hence you can be sure that the upgrade process will not end in a mess if something crashes in the middle, like it is the case with all present standard FreeBSD upgraders. Not sure if this helps the situation you're referring to or not, but portmaster will by default make a backup package of each port that it updates, so if something dies in the middle you could back out of it by hand if you need to. Yes, so does portupgrade, but it deletes the backup as soon as the installation of the new port succeeds. This means that in the event of a crash in the middle you remain with a half upgraded system, and no way to backup completely to the previous working state
Re: Utility for safe updating of ports in base system
On Thu, Mar 20, 2008 at 05:59:28PM +0800, Denise H. G. wrote: Michel Talon [EMAIL PROTECTED] writes: Actually I don't think a batch download and install process would help much, especially for a freshly installed system because it might be a huge download job and much waiting time if one is going to install GNOME/KDE etc. from scratch. Perhaps the new `pkg_upgrade' could provide versatile options to complete such tasks. In fact a batch download, followed by batch install is much faster than constant interspersing of backup, download, install, etc. like portupgrade does. In particular there is only one ftp connection for downloading everything which cuts on time, and you can do backups at the same time. If you don't beleive me you can try the prototype (in python) that i have written a year ago, and which does precisely that: http://www.lpthe.jussieu.fr/~talon/pkgupgrade (which needs http://www.lpthe.jussieu.fr/~talon/pkg_save.py) Most of the time in the script is spent recomputing the INDEX for all installed files, because i assumed the INDEX is not necessarily up to date. -- Denise H. G. darcsis AT gmail DOT com -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Utility for safe updating of ports in base system
On Thu, Mar 20, 2008 at 09:34:38PM +0800, Denise H. G. wrote: Yes, I've had great impressions by the debian's apt- tools. But it seems that the debian package servers maintain an index or something for all the packages. And if you want to upgrade or install a certain package, you just fetch the meta info for that package from the package server and do a comparison with your local index. This makes versioned dependencies rather easy to play around. Indeed there is a compressed file on the Debian repository, containing all information on each available package. It is stored locally by apt-get when you run apt-get update in a custom database. Similarly apt-get maintains information in the database of the installed packages. Hence comparison is easy and fast. In the FreeBSD case there is always an INDEX file in the FreeBSD repositories which lists similar information (perhaps not enough information) for each package. So in principle one could do similar things as Debian does. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Utility for safe updating of ports in base system
On Thu, Mar 20, 2008 at 01:12:06PM -0700, Doug Barton wrote: Fair enough, but can we please come quickly to a consensus on what _all_ of the requirements should be? Two things I'd like to avoid. One is the feeling that no matter how many hoops I jump through, there is always going to be one more placed in my path because we really don't want portmaster in the base. The other is frustration on the part of any student brave enough to tackle this task. Now that it is clear that 2 different things are desirable, a utility to upgrade by ports, and a utility to upgrade by packages, may i say that i agree completely that portmaster does the first perfectly, and should be in the base system, notably since it is a shell script which doesn't cost anything. But i remain convinced that the second one is also necessary and in fact much more important. Since portmaster is already here, a SOC project should concentrate on the second aim, which is perfectly summarized by the name pkg_upgrade (by opposition to port_upgrade). The ideas necessary to develop such a project are apparent in the ruby program portupgrade and/or my python pkgupgrade, but a C program is desirable so that there is no external dependency. More precisely portupgrade and pkgupgrade both use extensively data structures such as arrays and dictionaries (perl hashes) so it may be that using C++ and the STL containers is more convenient than C. You also need to look at the other side of that, which is an exponential increase in the number of package downloads, and the incumbent costs in terms of bandwidth, processor time, etc. All big Linux distributions, which have many times more users, incur this cost without apparent problem. For example my provider, which is a quite large one, has a mirror of many distributions, including Free and NetBSD, with incredible bandwith. See ftp://ftp.free.fr/mirrors I can download a DVD from my office at 100Mb/s from here at any time. I would venture to say that the problem you mention is really a non problem. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Utility for safe updating of ports in base system
Doug Barton wrote: So, I renew my inquiry. :) Is portmaster a suitable candidate to fulfill the role of the utility described, and if not, why not? At the risk of being flamed, i would venture to say that such an utility should be able to upgrade things based of *binary* packages, and consequently that portmaster is not a suitable candidate. For example pkg_add installs a binary package, if you want to compile and install you run make all install clean in the ports tree. One of the requirements of an upgrade system is predictability, this can only be achieved by using binary packages. Another requirement, in my opinion, is speed, and the lack of speed, which is completely hidden when you compile your packages will be immediately apparent if you try to use packages. Indeed portupgrade has options -P and -PP to work with packages which could serve as a prototype for a pkg_upgrade written in C, except that they work poorly, and in particular run slowly. In my opinion, an example of a correct pkg_upgrade type programm written in C++ is the Debian apt-get. It works predictably, fast, etc. One of its features, that i consider very important for correct operation, is that it computes the list of all packages to be deleted and all packages to be installed and asks the user if he agrees before doing anything. It fetches all necessary packages before installing or deleting anything. Hence you can be sure that the upgrade process will not end in a mess if something crashes in the middle, like it is the case with all present standard FreeBSD upgraders. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade installing unexpected dependencies
Robert Huff wrote: Matthew Seaman writes: Building your own INDEX is easy (just type 'make index' in /usr/ports) but very time consuming -- probably 45 minutes or so on a typical desktop box On a lightly loaded p4/2.2Ghz (with only 512mb of RAM) it routinely takes about 75 minutes. Robert Huff Last time i have built the INDEX on a core 2 duo machine, it took less than 10 minutes, in fact 8 minutes if i remember well, which is ways less than the numbers you are claiming. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TeTeX and TeXLive
Albert Shih wrote: I'm just want known if there are any plan to replace teTeX ports (the project as stop) by TeXLive ? I've send long time ago a mail to teTeX maintainer and I don't have any answer. I known that's nothing urgent, but without tex the live is hard ;-) Well, TeX itself is frozen since many years, so the differences between TeTeX and TeXLive are of the order of the infinitesimal. It is not like you could not do happy texing using TeTeX. Of course the migration to TeXLive will have to occur but i understand that it is not an ultra hot priority. Personnally i would be happier with a distribution much lighter than TeTeX, i think the only progress of any interest in all that stuff is pdftex. If only i could put Latex2e in the trash can ... -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: duration of the ports freeze
Aryeh M. Friedman wrote:
My main issue is the lack of good depenancy tracking
Dependency tracking is a manual operation of the port maintainer.
There is no way to automatize it, because there is a lot more in
dependencies than shared libraries (which could be tracked
automatically). As such it is as good or bad as the port maintainer, and
there is no way to change that. You will always encounter ports with
huge and irrelevant dependencies, instead of the ideal smallest
subset allowing the port to run.
(leaving it to the preview of each port I think is asking for it in
the long run) and some rather inconsistent behaviour between say the
following three options:
cd /usr/ports/{some metaport}
make install
In my non orthodox opinion, this should be reserved to port developers
and similar power users who require maximum flexibility. For casual users
flexibility is not required at all and is more a hindrance than a bonus.
portinstall {some metaport}
Portupgrade has never worked correctly and will never, for a lot
of objective reasons supplementing the implementation choices.
and
pkg_add {some metaport}
In my opinion, things will be better when people will finally be
convinced that binary packages are the way to go, and then use a *good*
package management system such as apt-get. A functional upgrade system
can be built for packages, but cannot for ports, for obvious reasons.
The OpenBSD people have understood that, but now it appears that
most FreeBSD people are happy with the source based system, and all the
problems going with such a choice.
--
Michel TALON
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Proposal for another category in INDEX: common_deps
Doug Barton wrote: and then mainly as a resource to make easier the lives of the people that write ports management software. Well, I'm one of those people, and portmaster ignores the index file altogether, for whatever that's worth. Me too for pkgupgrade. In my case the rationale is that, if something has to be compiled on the machine, it is best that the information is exactly compatible with the state of the ports tree on the machine. So like portmaster, pkgupgrade recomputes the Index fields for all installed ports and their dependencies. This is no big deal, uses less than a minute on a modern machine, totally negligible compared to the time for downloading distfiles or packages, or running pkg_delete or pkg_add. In pkgupgrade case one needs to deal with both binary packages and ports, so RUN_DEPENDS is used to discover dependencies of packages, and all other fields coalesced to discover dependencies of ports. There is of course a further subtelty: you have to compare old and new ports which may have changed name in between. The rule i have taken is to systematically use the most recent name as it appears in the ports tree, and evolve old names following the MOVED file (perhaps recursively) to be able to compare them with new names. This leaves on the border of the road ports which have disappeared in between, but anyways you cannot upgrade them by source ... I think that portmaster does more or less the same, while, if i don't err, portupgrade doesn't and tries to guess new names using heuristics, which sometimes spectacularly fails. Well, all this to say that, for the purpose of upgrading a port, it is the coalesced values of fetch, extract, etc. which is of interest. Of course, for other purposes, like Mark Linimon says, these fields may have individual interest. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Proposal for another category in INDEX: common_deps
Matthew Seaman wrote: Another interesting idea would be to separate out the LIB_DEPENDS data. At the moment there is a separate LIB_DEPENDS variable that can be used in Makefiles, but the INDEX processing includes the LIB_DEPENDS data with both the BUILD_DEPENDS and the RUN_DEPENDS fields. Keeping LIB_DEPENDS separate should allow a useful optimization in the case of shlib ABI version number bumps. Clear that you are the author of http://www.infracaninophile.co.uk/portindex/ and so know the state of the Index stuff from inside out! Personnally i think there are far too many totally useless categories here, as you are saying, only RUN_DEPENDS and BUILD_DEPENDS have any usefulness, the first if you install from packages, the second if you install from ports. It is totally irrelevant to know if a dependency is FETCH, EXTRACT or whatever, since you need it anyway to build the port. Merging LIB_DEPENDS in both BUILD and RUN is justified since you need the libraries both for compiling and for running the port. Introducing a lot of dependency categories renders writing an upgrade mechanism very complicated. Either you coalesce everything into one big category, voiding the distinctions of their content, or you have to introduce an infinitely complicated logic to take care of them. For example you explain that knowing only LIB_DEPENDS would help knowing what to upgrade when gettext is bumped. But other ports may have important dependencies not going through LIB_DEPENDS. You need a crystal ball to disentangle all the cases. An upgrade mechanism can proceed with a mixture of packages and ports, for example portupgrade -P. The only relevant info for determining what to install or build previously is RUN_DEPENDS and BUILD_DEPENDS. Everything else is garbage. The Debian people have a simpler situation with apt-get, they have only one sort of dependency to consider, the equivalent of RUN_DEPENDS. Hence they can build a reliable sorted graph of dependencies. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Keeping track of automatically installed dependency-only ports
Doug Barton said: Jeremie Le Hen wrote: Hi, Is there a way to track dependency-only ports, so that if I install port0 which requires port1 which in turn requires port2 and so on, deinstalling port0 will deinstall portN up to the first one required by another port or one I explicitely installed. I realize that this is an old post, but the thread it generated indicated that there is demand for this kind of functionality, and no solutions were presented that I could see. Portmaster actually has what I believe you are looking for. Finding installed packages which have no REQUIRED_BY is easy, portmaster do it, check_pkg.py do it, but i don't think this is the solution of the problem. For example, port1 may require port2 which itself requires port3. Assume you remove port1, and that, as a consequence port2 and port3 are no more necessary. It is only port2 which has an empty REQUIRED_BY, as long as you have not removed port2, port3 mentions it in REQUIRED_BY. So the deletion should have to be recursive. Moreover on a large installation you may have a large number of ports that should be removed and should require user approval to do so. But it is hard to remember several months after the fact, if a port without REQUIRED_BY has been installed as a dependency or for a precise reason. The only reliable way to detect ports which have been installed as a dependency is to create a database indicating which ports have been required by the end user, and which ones have been automatically installed. Such a database doesn't exist in the FreeBSD ports system, and as a consequence, it cannot do a good job of cleaning the installed packages. Moreover due to the tendency of some configure scripts to detect automatically installed libraries and behave accordingly, the presence of unwanted and uncleaned ports may be not only a small inconvenience, but may have bad consequences. So i think it should be wise to introduce a database as indicated above, in the same way it has been introduced in aptitude as an enhancement of apt-get. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Keeping track of automatically installed dependency-only ports
On Sat, Jul 07, 2007 at 09:57:59AM -0700, Doug Barton wrote: The only reliable way to detect ports which have been installed as a dependency is to create a database *shudder* You just tripped over your own argument here. There are plenty of ways that we could recognize a port that was installed as a dependency. The one that comes immediately to mind is to create a flag file in /var/db/pkg/foo (or /var/db/ports/foo) to indicate that the port was installed as a dependency. It would be trivial for portmaster and portupgrade to do this, slightly more complicated for it to be done in bsd.port.mk, but not impossible. I agree completely with you. Of course when i say that a database has to be created, this may very well be reduced to a flag somewhere in /var/db/pkg. For me, /var/db/pkg is a database describing the installed ports. Wether abusing the filesystem to create this database is good for performance is a completely different problem, at least it has the advantage of being very transparent. indicating which ports have been required by the end user, and which ones have been automatically installed. Well, what happens if an application (rather than a library) gets installed as a dependency, but you decide that you like that application, and want to keep it? How do you promote something from dependency installed to user installed? Indeed you are right, it should be possible to decide of such a promotion. Personally I think that portmaster's approach is the right one. If you accidentally delete something that it turns out you really do need, you can always install it again. On the other hand, the presence of an empty +REQUIRED_BY file is a very reliable indication that something was previously installed as a dependency, but is no longer needed. Typically you can install the java jdk to do programming, and without any required_by stuff. If you accidently erase it, it will be expensive to recreate. Obviously this is not a very good example because this one you will remember. I was thinking more to some obscure ports that you install by curiosity. After several months, perhaps you discover it is on your machine, and you have some use for it. Perhaps if you had erased it, the distfile would have disappeared, or marked broken with new versions of FreeBSD, no more compilable, etc. I'd be interested to hear if others have opinions about this ... Sure this is a point of interest, the more opinions, the better. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Finding slowdowns in pkg_install
Tim Kientzle said: One approach I prototyped sometime back was to use libarchive in pkg_add as follows: * Open the archive * Read +CONTENTS directly into memory (it's guaranteed to always be first in the archive) I can only concur with that. In my program http://www.lpthe.jussieu.fr/~talon/check_pkg.py i discovered that memory mapping +CONTENTS and then working in memory before rewriting it was around 5 times faster than reading line by line and parsing each line. See function fix_pkg_database(). By the way i am writing a new +CONTENTS fileand then renaming it, which avoids leaving a mess if something goes astray like portupgrade does. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Uggg!
Thomas Hummel wrote: Sure. But that doesn't explain why so many +CONTENT files were screwed up and why there isn't a easy or easier way to re-generate them. Portupgrade (at least pkgdb) has functionality to edit the +CONTENTS file with the aim of fixing the dependencies. So one may understand that if it is killed in the middle it may leave the +CONTENTS file screwed. It would be wise to move the file to +CONTENTS.BAK and then edit the +CONTENTS file, or edit a copy and then apply rename. You cannot regenerate the +CONTENTS file in a reliable way, because its content is depending on the way in which you installed software on the machine, from package or port, and then what was the building option for the port. Note that all files have an md5sum which willbe different for any variation! It is even dependent on the history of the pkgdb you have done, since this edits the file. Moral of the story, as other people are saying, keeping a backup of the pkgdb should be necessary before taking unreliable action. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index
Stephen Montgomery-Smith said: I suggest rewriting make so that variables are only evaluated on a need to know basis. or I have tried to do this. Of course a lot of people have thinked about it, and quickly realized that it was not going to work. In the bsd.ports.mk, evaluation of one variable may be dependent on some conditional, which may itself be dependant on some other variable, appearing as some target. This constantly happens in bsd.ports.mk. If you think about that, you convince yourself that a reduced make needs to understand targets, needs to understand conditionals, and needs to evaluate not only the variable under consideration, but but possibly any other. In other words, you need a full blown make. To gain some performance, a first idea would be to simplify bsd.ports.mk. I am convinced that a substantial part of the 4000 lines are historical crap which serve no useful purpose. There are tons of variables who have probably purely anecdotical interest. There are targets which could be happily suppressed. Of course, due to the complexity of bsd.ports.mk, rewriting it is certainly not an easy task. There is a freebsd port whose aim is to rewrite it, i don't know how far they are. The NetBSD people have completely rewritten the system, i have no idea if the new one is faster. The OpenBSD people have also rewritten bsd.ports.mk, with apparently much faster makefile. A second idea would be to multithread make, since modern machines will have a lot of cores. At present make -j something forks submakes and waits for their completion. This doesn't help for the problem at hand. However, multithreading the execution of a single makefile is certainly not trivial due to the interdependencies. Anyways, one of the things which cannot be a big factor is reading bsd.ports.mk from hard disk. It is certainly cached in memory when you run make index. On the other hand it is so big that it probably doesn't fit in cache, or probably only fits in caches of machines generously endowed. I have remarked that the difference of execution speed of make index between machines of similar speed but very different cache size (i am thinking Pentium 4 versus Core 2 Duo) is striking. It is less than 10 minutes on the big cache machine versus 30 minutes on the small cache one. If the cache effect is indeed dominant, then reducing the size of bsd.ports.mk by all possible means would be very beneficial. By the way an alternative system would be to use something other than make to do the job. This is what the Gentoo people are doing, using first a python based system, and now a C++ one (paludis). Here also i don't have any idea if it is faster. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Specs for saving old shared libs
Benjamin Lutz wrote: Benjamin Lutz writes: The last part seems to be the catch here. How about providing a tool that scans all binaries in the standard locations for what libs they depend on, and also allows the user/admin to specify the paths to binaries that he installed on his own, then outputs a list of unused libraries? Are you aware of libchk and portsclean? Oh. No, I wasn't. Well, I guess that solves this problem then :) Not completely because some programs install shared libraries in very non standard places, notably perl installs perl.so like this: /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so or mozilla installs mozilla libs in another strange place. And there are other ports which make use of such shared libraries, for example Gnome depends on the mozilla libs or inn depends on perl.so. Hence the only correct solution is to scan all files in a port, and determine if any of them is a shared library to keep a copy of it. This is what portupgrade does, as well as Cyrille Szymanski's pkg_save: http://www.lpthe.jussieu.fr/~talon/pkg_save.py The important point is: what do you do with shared libraries you have saved? Either you put them in /usr/local/lib/compat like portupgrade does, and you run ldconfig here, then there is no problem with these libraries but you have no real way to discover which are necessary, which are not (libchk cannot assert that since it looks only in standard places) or you can say like portmaster, i don't want to rely on this mechanism, you keep your copy and use it only in case some library is really missing and you don't know how to solve the problem in another way. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems running pkgdb -fF
multimedia/totem now uses gstreamer by default sed: 1: s|^\(@comment[: unbalanced brackets ([]) Perhaps there is a specific problem here, but i have observed corruption under FreeBSD-6.2. Several times on my laptop where various applications suddenly misbehave, rebooting cures that, but once firefox was corrupted and i had to reinstall it. Since it has several experimental drivers i can perhaps blame them. But once i have found completely corrupted +CONTENTS files on my desktop which has supported hardware. The corrupted entry was flagged by my check_pkg.py first time i used it on /var/db/pkg. Of course this is the sort of thing absolutely impossible to characterize. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
pkgupgrade
Hello, this is to report a revised version of my program, intended to upgrade a machine using mainly precompiled packages. All problems that i have seen or have been reported to me have been fixed. So i think it is reasonably suitable for use, and i have sticked a 1.0 label. I have also fixed all problems i have encountered with save_pkg.py, but Cyrille Szymanski will perform a better cleanup, so i have appended a 0.5 tag. So fresh copies can be downloaded from: http://www.lpthe.jussieu.fr/~talon/pkgupgrade-1.0 http://www.lpthe.jussieu.fr/~talon/save_pkg.py-0.5 They will be accessible as soon as the administrator will have fixed the apache configuration :-( (broken after a crash), or by email from me. This is an example of running it: niobe% ./pkgupgrade There are now 621 packages installed. Collecting installed packages. Building the updated index. Downloading INDEX from ftp server ftp.freebsd.org in directory /pub/FreeBSD/ports/i386/packages-6.2-release INDEX downloading finished. Building and filling the dependency DAG. Printing the upgrade list in UpgradeLog Total time spent in analysis: 01 minutes 20 seconds. Second phase, downloads and backups. Total time spent in downloads: 00 minutes 01 seconds. Total time spent in backups: 00 minutes 20 seconds. Writing upgrade shell script. Will remove 391 old packages. Will install 465 new binary packages. Will compile 7 ports. All tasks completed. ** Total time: 02 minutes 30 seconds. Here of course downloads and backups had been performed in previous runs, except for a small part of backups which are redone. So one can say that 2mn30s is the overhead of the program itself. Out of the binary packages, to be installed, 245 have been found on the FreeBSD-6.2 disk2 and so are not downloaded. Downloads take of the order of 10 minutes on a high speed connection, more on a low speed one, of course, but have to be done anyways. Backups take less time, and are performed during downloads. It is to be noted that, out of 600 installed ports, 200 will not be upgraded, because there is no more recent precompiled version, 400 will be removed and replaced by more recent versions, and only 7 ports will need recompilation. In the present case they are, as shown by the upgrade shell script: TOBUILD='print/pdflib graphics/blender-devel editors/vim emulators/kqemu-kmod devel/py-urwid audio/lame audio/faac' These are indeed not present on the FreeBSD-6.2 repository. Clearly these compilations will take very little time, and the quasi totality of ports will be upgraded through binary packages, as intended, including openoffice which is now found directly in the repository. Hoping that this will help maintaining FreeBSD boxes without spending hours doing it. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
pkgupgrade
Hello, this is to announce a first cut at an upgrading system more centered on packages than portupgrade or portmaster, so i have called it pkgupgrade. This is a python program, so not convenient for pytho-phobic people. You can find it at: http://www.lpthe.jussieu.fr/~talon/pkgupgrade as well as the companion program: http://www.lpthe.jussieu.fr/~talon/save_pkg.py written by Cyrille Szymanski who has kindly given me permission to publish it here. Both are of course under BSD licence. Here save_pkg.py is a program which does selective backing of old packages before an upgrade and can be run independently, but is called by pkgupgrade and is thus necessary. Running save_pkg.py -h gives usage information. A documentation explaining pkgupgrade can be found here: http://www.lpthe.jussieu.fr/~talon/freebsdports.html#htoc19 but basically, one creates a clean directory and run pkgupgrade here as simple user. There are no options. The directory will be populated with self-explanatory stuff. Be prepared to use a lot of space in the directory, however there is no destructive action at all. A good way to reduce downloading and disk consumption is to mount the second disk of the freebsd release set under /cdrom, previously to run pkgupgrade. It will locate necessary packages here. The main end result is a shell script able to do the upgrade at one stroke. This is dangerous, but it is easy to check the shell script, so the danger is certainly less than wiping everything and reinstalling, which is at present my preferred method. Of course this program implements my pet peeves, reducing port compilation to the minimum, because in my experience this fails far too often, determining dependencies previous anything else, downloading all downloadable precompiled packages before taking any destructive action, and knowing in advance, before the system is ruined what exact steps will be taken. Then wiping everything which needs to be upgraded and reinstalling fresh stuff. In other words it is far more inspired by the Debian apt-get system than by progressive systems like portupgrade or portmaster which update things by little steps. In my experience the Debian system is far more reliable than the FreeBSD one, but such reliability will never be accessible to FreeBSD as long as *all* ports are not available as packages. Obviously pkgupgrade needs further polishing, it is, like portupgrade, somewhat complex, and bugs can easily creep in short as well as complex programs. I will be very happy if i get feedback on bugs or misbehaviors, and so will Cyrille. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Dependency question
Hello, since i am writing a substitute program to portupgrade, i have noticed a problem that i have hard time figuring out, and i would like to sollicit the advice of more experienced people. The point is, what to do about ports which have been installed as dependencies of some other ports, but the dependency has changed afterwards and nothing particular occurs in the MOVED file. The specific example i have in mind is the following. Installing gnome-session brings as dependency a zeroconf program. Some time ago, it was howl, now it is avahi. If i upgrade the installed software without further consideration of the problem, both howl *and* avahi will be installed (and howl upgraded). If MOVED mentioned that howl has disappeared, then i would have only avahi, which would be more correct. Or it could be mentioned that howl has been moved to avahi, while in fact there is no mention of howl. A somewhat similar problem occurs with python. I have a lot of programs depending on python, and python installed. But in more recent ports tree, all these programs are marked dependent on python24, so if i upgrade, i will have both python24 and python installed. Presumably they are presently the same, but python will become python25. However nothing in MOVED helps to solve this issue. At present the only simple thing i can do is follow MOVED for what is mentioned in MOVED, try to upgrade the rest, while killing disappeared ports, and hope that dependency will restore an appropriate system. Do you have better ideas? By the way, a first step program is available here: http://www.lpthe.jussieu.fr/~talon/analyze_pkg.py It will analyze installed packages, follow MOVED, and compute the INDEX for all installed packages and all their dependencies, that it discovers while computing the INDEX. In my case i have around 600 installed ports, it discovers around 100 dependencies, and the procedure takes around 1mn25 (on a P4, 3Ghz). The result can be found in the files ErrorLog and INDEX. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Server to browse ports tree.
Some time ago, people discussed the idea of writing an http server allowing to browse the ports tree in the same way as one can do using the README.html. I have just written one, in python, using the exact same html templates which make readmes uses. Of course it needs an INDEX file to work. It is free and can be downloaded here: http://www.lpthe.jussieu.fr/~talon/show_index.py To run it simply make it executable and launch it. It will open a port on 8080 that one can browse with any browser on http://localhost:8080, of course if the browser is not instructed to go looking on some proxy. If port 8080 is inconvenient, on can launch it as ./show_index.py port number This server is very snappy for single use, it is much faster and cleaner than building the README.html (but requires python, of course!). Someone with html skills, not my case, could improve on templates, however. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
