Does www/chromium work?
Hello, Since there are no binary packages (why? I don't see where the Makefile prohibits it?), I'm still upgrading chromium by building it with portupgrade. But, it looks like the latest version is broken - it segfaults in protobuffers: (gdb) bt #0 0x00080e26d7d2 in __dynamic_cast () from /lib/libcxxrt.so.1 #1 0x000807c873c4 in google::protobuf::Message::CheckTypeAndMergeFrom () from /usr/local/lib/libprotobuf.so.8 #2 0x02e5ddd2 in ?? () Google finds a sort-of similar problem in Ubuntu: https://bugs.mageia.org/show_bug.cgi?id=13187#c15 ... which appears to be caused by using the non-bundled protobuffer library, the same as in FreeBSD. However, simply patching Makefile to have use_system_protobuf=0 breaks the build, stating missing files. This is chromium-36.0.1985.143_1 on FreeBSD 10.0-RELEASE-p1. Is anybody running chromium? signature.asc Description: OpenPGP digital signature
Re: Does www/chromium work?
On 20 August 2014 13:30, René Ladan r.c.la...@gmail.com wrote: This is chromium-36.0.1985.143_1 on FreeBSD 10.0-RELEASE-p1. Is anybody running chromium? Yes, but as soon as you sign in the Chromium you'll hit the above error. See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192821 FWIW, I've hit the crash after login bug about a month ago on my earlier version (or at least an earlier build, I don't know if it was actually an earlier verion) and have approximately pinned it down to chrome extensions. Somewhere in the Chromium login dialog there's a checkbox or a button to skip synchronizing your chromium desktop with what's on Google's servers. Using this, I've managed to login correctly, and later found that there are options in Chromium settings to only synchronize certain parts, like History, Extensions, Bookmarks, etc. Chromium worked for me when I disabled synchronization of Extensions, leaving other parts enabled. ___ 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
Synchronizing package defaults with Linuxes?
Hi, What do you think, as users and port maintainers, of the idea to synchronize some high-impact package defaults with Linuxes? My major concern here, and the reason I'm writing this post, is for package versions for LAMP and LAPP stacks and making things easier to use pkgng. For example, for the last couple of years, every major Linux distribution had stabilized on PostgreSQL version 9.1, while FreeBSD's default is still 9.0. It makes things difficult when developing cross-platform solutions. I want to use pkgng as much as possible, but this particular detail is making it nearly impossible to use pkgng for server maintenance since all dependent packages using PostgreSQL require postgresql-client version 9.0, which conflicts with any other version installed. Tomorrow, Ubuntu will release its next LTS release 14.04, which will have PostgreSQL 9.3. This is just an example, there are other such cases. I'm not saying that Ubuntu is the one true Linux to follow, but for example in this case, Debian 8.0 will be frozen later this year and it will also have PostgreSQL 9.3. CentOS is a lost cause to follow since RedHat has designated RHEL version 6 for production use until at least 2016. What do you think of the idea of syncing versions in general, and this example of PostgreSQL in particular? signature.asc Description: OpenPGP digital signature
Berkeley DB 4.1
Hello, I'd like to start a discussion on changing the default BDB port from 4.1 to something more recent. bdb version 4.1 was last released in 2002: README: Sleepycat Software: Berkeley DB 4.1.25: (December 19, 2002) There are some ports which have an unexpected dependacy on bdb via APR (apache22, subversion), which does is not wrong in itself, but is somewhat unelegant (as a personal opinion of course). I've found this previous discussion: http://lists.freebsd.org/pipermail/freebsd-ports/2013-February/081444.html And while the argument seems valid, it also doesn't have an estimate of which / how many ports will break with a more recent bdb. Could an experimental port build be done with setting WITH_BDB_VER to either the most recent 4.x version (WITH_BDB_VER=48), to the last Sleepycat Licensed version (50) or the recent version in ports (60) to see what breaks? signature.asc Description: OpenPGP digital signature
Re: Berkeley DB 4.1
On 12/09/2013 13:09, Matthew D. Fuller wrote: On Thu, Sep 12, 2013 at 12:57:06PM +0200 I heard the voice of Ivan Voras, and lo! it spake thus: And while the argument seems valid, it also doesn't have an estimate of which / how many ports will break with a more recent bdb. FWIW, I've manually pushed all the systems I've managed to higher versions than 4.2 for years. I remember having 4.6 around a lot. In a quick look around now, I see 4.8 on everything but one system that's running 4.7, servers and a couple workstations. I can't recall _ever_ seeing a breakage. Yes, I've had WITH_BDB_VER?=48 in my standard /etc/make.conf I carry around in every system for so long that I don't even remember when I've added it :) signature.asc Description: OpenPGP digital signature
Re: pkgng update - No address record
On 01/02/2013 11:05, Matthew Seaman wrote:
On 01/02/2013 09:46, Ivan Voras wrote:
Hello,
I know that the default pkgng repos are not up yet (probably...) but
even so, when I try to run pkg update on two machines, I get this error:
# pkg update
Updating repository catalogue
pkg: http://pkg.freebsd.org/freebsd:9:x86:64/latest/repo.txz: No address
record
However, there are other machines where it succeeds:
# pkg update
Updating repository catalogue
Repository catalogue is up-to-date, no need to fetch fresh copy
The only difference I see is that the ones that fail have pkg 1.0.7 and
the one that works is 1.0.2. Is this expected?
Could you show us the pkg.conf from the various machines please?
On all the machines, the pkg.conf is a copy of pkg.conf.sample and the
only uncommented line is:
PACKAGESITE : http://pkg.freebsd.org/${ABI}/latest
I've verified that the URL is the same on two of the machines. However,
the two machines are on different DNS servers. I've tried to debug using
dig -t SRV pkg.freebsd.org but on both machines it shows no response.
I've also tried this:
http://dnsrlookup.onlinetoolkit.org/?host=pkg.freebsd.orgrecordtype=SRV
with same results, so it's probably not the way to debug it :)
signature.asc
Description: OpenPGP digital signature
Re: [HEADS-UP] Announcing the end of port CVS
On 07/09/2012 14:36, Beat Gaetzi wrote: For those reasons by February 28th 2013 the FreeBSD ports tree will no longer be exported to CVS. Therefore ports tree updates via CVS or CVSup will no longer available after that date. All users who use CVS or CVSup to update the ports tree are encouraged to switch to portsnap(8) [1] or for users which need more control over their ports collection checkout use Subversion directly: I'm assuming that CVSup also covers csup? Will csup be removed from base? signature.asc Description: OpenPGP digital signature
pkgng problems
Hi, I attempted to try pkgng, and failed: 1) I would like to request some documentation be added in the ports-mgmt/pkg port, to the pkg-message file, instructing to set up the pkg.conf (by copying the pkg.conf.sample file) before starting to do anything with pkgng. I would also like to request this same documentation added to the FAQ at https://github.com/pkgng/pkgng/blob/master/FAQ.md#0, and that the error message pkg: PACKAGESITE is not defined be changed to e.g. pkg: PACKAGESITE is not defined - pkg.conf not found or something similar indicating how to solve the problem. 2) The pkg.conf.sample file does not contain a list of valid repos: repos: default : http://example.org/pkgng/ repo1 : http://somewhere.org/pkgng/repo1/ repo2 : http://somewhere.org/pkgng/repo2/ ... and apparently this makes running pkg update impossible as it exits with the completely useless error message Broken pipe. At least this error message should be changed. I would like to request that pkg.conf.sample contain valid repos by default. While at it, where on the web is the list of valid repos and why is the documentation (README and the .sample conf file) not referencing it instead of specifying the abstract example.org addresses? (I know pkgng is not finished, but this way you are not going to get any enthusiastic testers...) signature.asc Description: OpenPGP digital signature
New ports - Bullet Cache
Hello, I've submitted a couple of new ports, and I'd like to ask someone to take a look at them and commit them: http://www.freebsd.org/cgi/query-pr.cgi?pr=164872 I'm not sure how to handle the shared library installation issue (lines 36,37 in mdcached/Makefile). signature.asc Description: OpenPGP digital signature
New port - Bullet Cache
Hello, I've submitted a couple of ports, and I'd like to ask someone to take a look at them and commit them: http://www.freebsd.org/cgi/query-pr.cgi?pr=164872 I'm not sure how to handle the shared library issue (lines 36,37 in mdcached/Makefile). ___ 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: Libreoffice plan
On 24/08/2011 12:13, Baptiste Daroussin wrote: libreoffice as openoffice are difficult ports to maintain, to not hesitate to join the office@ team to help, test, discuss about the office related task. Not volunteering but just wanted to thank you - I really couldn't use FreeBSD on any desktop without OOo/LO! ___ 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: what next for the pkg_install rewrite
On 2 September 2010 09:34, David Forsythe dfors...@freebsd.org wrote: Eh, why didn't this thread spring up before summer of code got under way (or during the many weeks it was running)? Yes, that would have been beneficial. For what it's worth, I've been trying to start it without success for years :) As for your other questions, I think you should read http://wiki.freebsd.org/Pkg_install2_specs - most of them will be answered there (also follow the wiki links). The repository format is something that you guys didn't really touch on that I think could use some fixing, but I'll wait to see where this all goes and maybe throw some ideas on a wiki page later on. Repository format as in ftp server layout or something else? ___ 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: what next for the pkg_install rewrite
On 30 August 2010 09:27, Anonymous swel...@gmail.com wrote: We can as well use Lua tables to store package database. Their syntax is close to JSON. Besides, I think it's better to divorce ports from base so that pkg_* tools can evolve faster and are not limited to dependencies from base. The only thing we'd need to leave in base is smth like pkg_bootstrap. IMO, this chicken and egg problem is getting quite annoying. Speaking of Lua, I had a thread on this in -current which went IMO fairly well, mostly because Lua is a clean and easy language to import compared to, e.g. Perl, TCL or Python. As I see it, there will not be heavy opposition if Lua is to be imported. In short, if there is going to be a scripting language for pkg_*, Lua is sort-of pre-approved - as opposed to ksh and others mentioned here. ___ 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: what next for the pkg_install rewrite
On 30 August 2010 10:22, Baptiste Daroussin b...@freebsd.org wrote: I have begun that: http://wiki.freebsd.org/Pkg_install2_specs if you could add ideas and all stuff you have in mind about what has to be and what could be in pkg_install, I'll cleanup the page after some time, when all the needed discussion would be done and will transform this page into real specifications. I like the proposal for the manifest format. I've added some small ideas. Concerning having pkg_install into base or not, I really have no opinion? Oh it should be in base, the operating system isn't complete without it. ___ 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: what next for the pkg_install rewrite
On 20/08/2010, Garrett Cooper gcoo...@freebsd.org wrote: 1. SQLite was killed before because of complexity and because it was needs another package in base that isn't BSD licensed. That's why And... both ideas are completely wrong. SQLite can be imported as a single C file + header, which you must agree is practically the optimum, and its license is public domain which is, if anything, freer than BSDL and eminently compatible with it. everyone in the know has been pushing for BDB 1.8x (in base). People BDB in base offer exactly one (1) single feature, if you can call it that: storing and retrieving key-value binary blobs. It has no practical concurrency support, it's locking is laughable and upgrading data stored as binary blobs is even more nightmarish than maintaining the current plist format (and it will lead to similar uglyness soon - rather than upgrading the data piece called x, I'm sure developers will introduce new keys called x_extdata, x_moredata etc etc). SQLite on the other hand solves all these in the following way: 1) stores proper records, not blobs 2) has proper locking concurrency support, ACID 3) the database schema can be modified on the fly for upgrading - fields can be added to existing table while preserving data. 4) is endian-agnostic, 32/64-bit agnostic and portable (I mean the database file) to an extremely large number of platforms. It is already used as a system database in OS X, iPhone and Android. Note that I'm promoting SQLite to replace the /var/db/pkg/* tree of directories and files with ad-hoc structure - all data in there should be in one SQLite database, which is stored in a single file. suggested that to me back when I was trying to get off the ground in GSoC 2006, they did it to you before Ivan, and I'm sure they've done it before in the past. We need to implement things in terms of BDB first, but make the APIs generic enough so that it _could_ be extended to SQLite if people chose to do the work later on. Not planning an API for a transactional database in the first place will bring the whole thing down in the long term, and in any case will certainly push things 10 more years in the future. Note that SQLite can *not* be considered a drop-in replacement for BDB (any version of BDB) because in that case you will gain far less than is optimal. If you haven't used SQLite yet, please try it, from C, and then see if you can reevaluate your comment on its complexity. If you don't like SQL, this is also fine. You are not out of the game, there are many other parts to work on. As for backward compatibility: basically it can be done in two ways: 1) build a one-time converter that will read the present plist database and output a new database or 2) build a compatibility layer which would support both the old and the new format at the same time, so people upgrading will continue to use their old data. I consider the latter wasteful in terms of developer resources and because bit-rot will eventually make support for the old format decrepit. 2. XML is a bad idea. Great in theory, wonderful in my browser, but a bloated plaintext file with a lot of complexity. I would prefer a database solution that could be dumped to a simple text file format if needed. XML, at least in my proposal, would not be used for the system package database, but would replace (either in part or all with a single file) today's + files in the packages, together with other purposes where some metadata transfer is required. That said, I would also be happy with other self-described formats like JSON. XML is the front runner because it's more standard (industry standard, whether someone likes this fact or not!) and there is already a parser in base. Again (and I can't overemphasize this): no matter what we do, say, etc, unless we have buy-in from portmgr beforehand on anything here, the work will never see a ports/src CVS/svn repo, etc. This includes work done for past GSoCs, and current GSoCs. With all respect to portmgr, I expect it to keep a cool head and acknowledge the following: 1) Decisions must be made on objective terms which include consideration for clean / elegant implementation, long-term maintainability and standards. If there is to be a rewrite, it must be built to stand the test of next 10 years of usage, and not start compromising even before it is started. 2) Except in extreme cases, portmgr should decide based on functionality and not have that much say in the specifics of the implementation. Basically, the portmgr should in the first place approve the feature spec, and the src people should worry about the details of what can and cannot be done. This is not a src vs portmgr war, this is separation of duty. (of course there are overlaps in people's memberships) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to
Re: what next for the pkg_install rewrite
On 19/08/2010, Julien Laffaye jlaff...@freebsd.org wrote: There are a lot of areas of potential discussions: packing list format, local database format, ... In my opinion, trying to be 100% compatible with the actual tools will slow down the project. I am thinking, for example, about the slave/master modes which made sense when we used a temporary directory, but less if we want to extract the files to their final destination via libarchive. Then, this specification will need to be approved by portmgr@ so the actual coding can start! Like many people in this discussion I have done some work on pkg_* and for what it's worth, here's what I would like changed: - Fully specify and separate package name from its version - metadata should not record apache-2.2.13 but apache, 2.2.13 to better support upgrading and dependancies. - Debian-like dependancies - the suggests variety, as well as ranged-dependancies - package X depends on Y versions W through Z. - A wrapper for all pkg_ tools to use, implemented with libarchive. This wrapper would allow preparation of the whole archive layout in-memory, together with simulating common file system operations like chmod, chown, rmdir, mkdir, rename, unlink, etc. and would as a last step offer to serialize this virtual file system to an archive. - Policy to forbid the lazy-maintainer dances with package names, such as package names depending on config flags used, etc. - this probably needs more thinking through. Essentially, I want to avoid things like what happened to the apr port - names like apr-ipv6-devrandom-gdbm-db42-1.4.2.9.3.1_1 Of course, this would better be if documented somewhere semi-permanent - in our wiki for example. ___ 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: what next for the pkg_install rewrite
On 19/08/2010, jhell jh...@dataix.net wrote:
Adding to this I would like to see a central database created for
packages that have been removed like in Slackware Linux. They keep a
file in /var/log/preserved_packages with a flat text format with the
file name looking like:
${PORTNAME}-${PORTVERSION}${PORTREVISION}-`date +%Y%m%d%H%M%S`
Ah yes, you reminded me of this other thing: I would also suggest
getting rid of text files carrying rich information in ad-hoc formats
:)
I'm not saying XML should be the only choice, but it *is* well
supported - expat is even in base as libbsdxml.
While suggesting nebulous things I know will be hard to pass near a
lot of people: sqlite is *the* choice for any record-based file
databases today. The single most important thing I'll promote with it
is its transaction capabilities and ACID - these would get much use if
parallel operations (upgrades / installs) are to be supported. There
are a ton of other reasons too.
I started writing this a long time ago but abandoned it because of
strong opposition: http://wiki.freebsd.org/PortsUsingSQLite - maybe it
would help at this time.
___
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: Full Unicode Support for FreeBSD
On 03/16/10 11:10, Gergely CZUCZY wrote: I think he is referring to the syscons. Syscons lacks UTF supports, though some work is being done: http://wiki.freebsd.org/SysconsUnicodeProject Correct sorting (collating) is another problem. ___ 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: Full Unicode Support for FreeBSD
On 03/16/10 13:55, Alexander Churanov wrote: Hi folks! I was initiating the work on syscons driver some time ago, then was too busy and my part of the work stalled for about a year. At present I am going to continue working on this. One of my students, Vladislav Soldatov, is willing to continue working on syscons and fonts with me. I have a branch in Perforce, with mapping from unicode to 8-bit fonts implemented. Whom should I contact for: 1) Grant permissions for Vladislav to access the Perforce branch? 2) Discuss the state and the future of the work. I'd like to ensure that we are not doing the same things as other engineers and everybody is aware of changes? Please ask these questions on freebsd-arch@ or freebsd-hack...@. ___ 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: [Firefox] Why we can't update..
Martin Wilke wrote: Before we get more mails with the question why we not update firefox to 3.6, the answer is easy, nox@ found some problems with some plugins, this problem seems to be only FreeBSD releated under Linux or Windows seems to be works all fine. Some plugins crash with some open ASSERTS, we working on this problem but that need a bit time. So please wait a bit. Thanks! Thank to all of you who are working on FF :) No use in hurrying if it will end up badly - make it good before releasing it :) ___ 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
PkgTrans proposal
Re: BSDCan Ports BOF: http://wiki.freebsd.org/IvanVoras/PkgTransProposal It's there... if anyone's still interested, please contact me. ___ 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: HEADS UP multi processor compilations for everyone
Pav Lucistnik wrote: Two days ago, I have checked in probably most requested feature of last few years. Ports framework now systematically supports building ports on multiple processing cores. It is achieved by passing -jX flag to make(1) running on vendor code. Thanks for this very useful addition! To clarify: this is about making individual ports in parallel (make -j on each), not building multiple ports in parallel? signature.asc Description: OpenPGP digital signature
openjdk6 package not being built?
Hi, I'm looking at ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/java and there's no openjdk6 package. I guess the reason for it is that it depends on an existing JDK (diablo-jdk1.6.0) for building, but this is precisely the reason why it should be available independently of encumbered JDKs (and to avoid having to build two JDKs just to have one). Any chance it could be kludged over so that it makes it into downloadable binary packages? signature.asc Description: OpenPGP digital signature
On pkg_trans
Hi, I'll probably have some time in the next few days to work on pkg_trans again, but first I'd like to get some input on the whole thing. The last time I talked about it I've made code available but I've received no feedback. More information on pkg_trans can be found in the list archives or on these pages: http://wiki.freebsd.org/IvanVoras/PkgTransProposal http://ivoras.sharanet.org/blog/tree/2008-10-13.addition-to-freebsds-package-infrastructure--pkg_trans.html Those pages also carry links to the code. I'm not a ports committer and I don't want to tell people who are how to work on their project but I think pkg_trans is important enough that it should require a policy decision - if it's accepted, pkg_trans should go into the base system. I know that there are utilities than can do some or all of what I've planned for pkg_trans but one important point of pkg_trans is that it should be integrated into the regular base package infrastructure, not requiring external utilities, runtimes or libraries. Some implementation notes: * I've avoided changes to the base utilities. A separate utility, pkg_trans, is called by the transaction-aware utilities * Client-side utilities are added to the pkg_install library (lib.h, etc.) * Transaction records are kept as text files. I think it would have been significantly better if sqlite was used but there was great opposition to importing sqlite into the base system the last time I brought it up so this is the last mention of it (in context of pkg_trans :) ) * If it's accepted, I'll maintain this addition to the utilities (of course, everyone's invited to contribute). I'll also be a regular user of these features - I created pkg_trans because I want the functionality on my systems. * For the pkg_trans to be effective, it requires slight modifications to the ports Makefile infrastructure (basically, the install and deinstall targets should be aware of transactions) and external ports utilities (like portupgrade), which I can't do myself. If there's interest in finishing pkg_trans, now's the time to discuss it :) signature.asc Description: OpenPGP digital signature
pkg_trans progress
Hi, Some time ago I've written about an idea to extend the standard ports/package infrastructure with transactions. Here are some notes on it: http://wiki.freebsd.org/IvanVoras/PkgTransProposal I've been working on it, and the code itself appears to have severely bad karma, being twice almost completely lost in hardware or software failures, so I'm publishing it now so it doesn't get lost again :) The build tree is at http://people.freebsd.org/~ivoras/big/pkg_install.tgz To use it: * Extract it somewhere * Run make in the created directory * su to root * Run make install Now you have a new utility, pkg_trans, and additions to existing pkg_add and pkg_delete utilities. It's highly recommended you also add pkg_trans_save_deleted_packages=YES to /etc/rc.conf (suggestions for better placement of this configurable is welcome). To undo this, run make install from the normal build tree (at /usr/src/usr.sbin/pkg_install) and manually remove the pkg_trans utility. The additional pkg_trans utility is called by patched pkg_add and pkg_delete, to isolate transaction functionality and minimize changes to pkg_add and pkg_delete. It also serves to query transactions and undo them. The man pages are not yet updated, but the wiki page above has simple descriptions of new options. Here's what currently works: * Recording pkg_add and pkg_delete transactions (one invocation of pkg_add/pkg_delete is one transaction, no matter how many packages it touches). * Backing up of packages in pkg_delete transactions * Undoing those transactions * Querying transaction records. The transaction records are installed in /var/db/pkgtrans and /usr/ports/pkgtrans . For illustration, here's a sample console session with the new utilities. Note that sqlcached requires sqlite as a dependancy. Arguments to pkg_trans do the following: -l : list all recorded transactions, -i : show info about a particular transaction, -u : undo a transaction. The rest should be self-explanatory. v8:/home/ivoras/temp# ll total 1 -rw-r--r-- 1 root ivoras 14896 Aug 1 10:17 sqlcached-r4.tbz -rw-r--r-- 1 root ivoras 639829 Aug 1 07:26 sqlite-2.8.17_1.tbz v8:/home/ivoras/temp# pkg_info|grep sql v8:/home/ivoras/temp# pkg_trans -l 0 transaction records found. v8:/home/ivoras/temp# pkg_add sqlcached-r4.tbz pkg_add: warning: package 'sqlite-2.8.17_1' requires 'pkg-config-0.23_1', but 'pkg-config-0.22_1' is installed pkg_add: warning: package 'sqlcached-r4' requires 'pkg-config-0.23_1', but 'pkg-config-0.22_1' is installed v8:/home/ivoras/temp# pkg_trans -l 1 (2 pkgs added) Wed Oct 8 23:07:04 2008 1 transaction records found. v8:/home/ivoras/temp# pkg_trans -i -z 1 Transaction 1, started on Wed Oct 8 23:07:16 2008 ADD sqlcached-r4 ADD sqlite-2.8.17_1 v8:/home/ivoras/temp# pkg_delete sqlcached-r4 sqlite-2.8.17_1 v8:/home/ivoras/temp# pkg_trans -l 1 (2 pkgs added) Wed Oct 8 23:07:04 2008 2 (2 pkgs removed) (2 pkgs backed up) Wed Oct 8 23:07:40 2008 2 transaction records found. v8:/home/ivoras/temp# pkg_trans -i -z 2 Transaction 2, started on Wed Oct 8 23:07:55 2008 DEL,B sqlite-2.8.17_1 DEL,B sqlcached-r4 v8:/home/ivoras/temp# pkg_info|grep sql v8:/home/ivoras/temp# pkg_trans -u -z 2 pkg_add: warning: package 'sqlite-2.8.17_1' requires 'pkg-config-0.23_1', but 'pkg-config-0.22_1' is installed pkg_add: warning: package 'sqlcached-r4' requires 'pkg-config-0.23_1', but 'pkg-config-0.22_1' is installed v8:/home/ivoras/temp# pkg_info | grep sql sqlcached-r4A cache daemon using SQL for data manipulation sqlite-2.8.17_1 An SQL database engine in a C library w/ Tcl wrapper v8:/home/ivoras/temp# pkg_trans -l 1 (2 pkgs added) Wed Oct 8 23:07:04 2008 1 transaction records found. v8:/home/ivoras/temp# pkg_trans -u -z 1 v8:/home/ivoras/temp# pkg_trans -l 0 transaction records found. v8:/home/ivoras/temp# pkg_info|grep sql v8:/home/ivoras/temp# In addition, the utilities now create a file called +USER_INSTALLED in the install package database for all packages explicitely installed by the user (i.e. not pulled in as a dependancy). At least this is how it should work, I'm not sure I tracked down all cases when dependancies are pulled. There's currently little smart behaviour WRT undoing transactions depending on other transactions, etc. This is planned but seeing how I'm little short on time, patches are also welcome. Also, to make this truly usable, the make install infrastructure will have to be aware of this, and also the utilities like portupgrade. As I've said before, I cannot work on these so I'm hereby officially requesting help for those parts. Testers are welcome for this work, please report back even if it works well :) signature.asc Description: OpenPGP digital signature
Re: Is postgresql83-server broken?
Hi, Can someone else confirm this? Do your postgresql83-server ports build? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is postgresql83-server broken? (update: ICU and autotools problems?)
2008/9/1 Alex Goncharov [EMAIL PROTECTED]:
,--- You/Ivan (Mon, 01 Sep 2008 11:29:39 +0200) *
| Can someone else confirm this? Do your postgresql83-server ports build?
Builds for me:
$ ls -l Makefile
-rw-r--r-- 1 root wheel 10599 Aug 26 06:53 Makefile
$ md5 Makefile
MD5 (Makefile) = a2e5324a341aba72d86904c3f7453509
What problem do you have? With the same Makefile?
Yes, my Makefile is the same:
/usr/ports/databases/postgresql83-server md5 Makefile
MD5 (Makefile) = a2e5324a341aba72d86904c3f7453509
Are you using ICU?
My (first) problem is this: distfile contains the following:
MD5 (postgresql/pg-833-icu-xx-2008-08-28.diff.gz) =
94fb6634636cd36cb5fde449d76ece65
SHA256 (postgresql/pg-833-icu-xx-2008-08-28.diff.gz) =
c7d77dafe78afcf2e92567c7cdfda45dcfe41ea71efb2e326ef4f7eb66ec416b
SIZE (postgresql/pg-833-icu-xx-2008-08-28.diff.gz) = 5302
but the Makefile contains:
. if (defined(SERVER_ONLY) defined(WITH_ICU)) || make(makesum)
USE_AUTOTOOLS= autoconf:262
CONFIGURE_ARGS+=--with-icu
LIB_DEPENDS=icudata:${PORTSDIR}/devel/icu
PATCH_SITES+= http://people.freebsd.org/~girgen/postgresql-icu/:icu
PATCHFILES+=pg-833-icu-xx-2008-06-11.diff.gz:icu
. endif
e.g. the ICU patches are mismatched:
# make
=== Vulnerability check disabled, database not found
=== Found saved configuration for postgresql-server-8.3.1
=== Extracting for postgresql-server-8.3.3
= MD5 Checksum OK for postgresql/postgresql-8.3.3.tar.bz2.
= SHA256 Checksum OK for postgresql/postgresql-8.3.3.tar.bz2.
= No MD5 checksum recorded for postgresql/pg-833-icu-xx-2008-06-11.diff.gz.
= No SHA256 checksum recorded for postgresql/pg-833-icu-xx-2008-06-11.diff.gz.
= No suitable checksum found for postgresql/pg-833-icu-xx-2008-06-11.diff.gz.
*** Error code 1
Stop in /usr/ports/databases/postgresql83-server.
*** Error code 1
Stop in /usr/ports/databases/postgresql83-server.
After I fix this manually with make makesum, there's another problem:
=== Configuring for postgresql-server-8.3.3
configure.in:22: error: Autoconf version 2.61 is required.
Untested combinations of 'autoconf' and PostgreSQL versions are not
recommended. You can remove the check from 'configure.in' but it is then
your responsibility whether the result works or not.
configure.in:22: the top level
autom4te-2.62: /usr/local/bin/gm4 failed with exit status: 1
*** Error code 1
Stop in /usr/ports/databases/postgresql83-server.
*** Error code 1
Stop in /usr/ports/databases/postgresql83-server.
I believe this is also related to ICU because of this fragment in Makefile:
. if (defined(SERVER_ONLY) defined(WITH_ICU)) || make(makesum)
USE_AUTOTOOLS= autoconf:262
CONFIGURE_ARGS+=--with-icu
LIB_DEPENDS=icudata:${PORTSDIR}/devel/icu
PATCH_SITES+= http://people.freebsd.org/~girgen/postgresql-icu/:icu
PATCHFILES+=pg-833-icu-xx-2008-06-11.diff.gz:icu
. endif
i.e. ICU is forcing autoconf 2.62 instead of 2.61. There is no
autoconf 2.61 in ports. It is needed because configure.in needs to be
patched for ICU. I think the ICU patch needs to be updated to the one
I attached (or maybe the fixed ICU patches were mistakenly not
committed before?)
(ICU is needed to get working collations with UTF-8).
--- configure.in.orig 2008-06-09 02:38:40.0 +0200
+++ configure.in2008-09-01 13:41:47.0 +0200
@@ -19,7 +19,7 @@
AC_INIT([PostgreSQL], [8.3.3], [EMAIL PROTECTED])
-m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.59], [], [m4_fatal([Autoconf version
2.59 is required.
+m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.62], [], [m4_fatal([Autoconf version
2.62 is required.
Untested combinations of 'autoconf' and PostgreSQL versions are not
recommended. You can remove the check from 'configure.in' but it is then
your responsibility whether the result works or not.])])
@@ -547,6 +547,14 @@
AC_MSG_RESULT([$with_openssl])
AC_SUBST(with_openssl)
+#
+# ICU
+#
+AC_MSG_CHECKING([whether to build with ICU support])
+PGAC_ARG_BOOL(with, icu, no, [ --with-icu build with ICU
support],
+ [AC_DEFINE([USE_ICU], 1, [Define to build with ICU support.
(--with-icu)])])
+AC_MSG_RESULT([$with_icu])
+AC_SUBST(with_icu)
#
# Readline
@@ -786,6 +794,19 @@
fi
fi
+if test $with_icu = yes ; then
+ AC_CHECK_LIB(icui18n, ucol_open_3_8, [], [
+ AC_CHECK_LIB(icui18n, ucol_open_3_6, [], [
+AC_CHECK_LIB(icui18n, ucol_open_3_4, [], [AC_MSG_ERROR([library
'icui18n' is required for ICU])])
+ ])
+ ])
+ AC_CHECK_LIB(icuuc, ucnv_fromUChars_3_8, [], [
+ AC_CHECK_LIB(icuuc, ucnv_fromUChars_3_6, [], [
+AC_CHECK_LIB(icuuc, ucnv_fromUChars_3_4, [], [AC_MSG_ERROR([library
'icuuc' is required for ICU])])
+ ])
+ ])
+fi
+
if test $with_pam = yes ; then
AC_CHECK_LIB(pam,pam_start, [], [AC_MSG_ERROR([library 'pam' is required
for PAM])])
fi
@@ -883,6 +904,10 @@
AC_CHECK_FUNCS([ERR_set_mark])
fi
+if test $with_icu = yes ; then
+ AC_CHECK_HEADER(unicode/utypes.h, [],
Re: Is postgresql83-server broken? (update: ICU and autotools problems?)
Alex Goncharov wrote: ,--- You/Ivan (Mon, 1 Sep 2008 13:45:32 +0200) * | After I fix this manually with make makesum, there's another problem: Did you try this simple fix instead: diff Makefile~ Makefile 110c110 PATCHFILES+= pg-833-icu-xx-2008-06-11.diff.gz:icu --- PATCHFILES+= pg-833-icu-xx-2008-08-28.diff.gz:icu I just did it and so far my build is progressing well: Well yes, that's a D'OH moment for me - I went the whole round way to accomplish the same thing. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Is postgresql83-server broken?
There are two problems about this port that I've encountered yesterday and today; the first is that it defines USE_AUTOTOOLS= autoconf:262 and the postgresql source checks that autotools version is exactly 2.61 and bails if it's not. Second, ICU patches don't seem to be correct either in distinfo or in Makefile: /usr/ports/databases/postgresql83-server# make === BACKUP YOUR DATA! = As always, backup your data before upgrading. If the upgrade leads to a higher minor revision (e.g. 7.3.x - 7.4), a dump and restore of all databases is required. This is *NOT* done by the port! Press ctrl-C *now* if you need to pg_dump. === === Vulnerability check disabled, database not found === Found saved configuration for postgresql-server-8.3.1 === Extracting for postgresql-server-8.3.3 = MD5 Checksum OK for postgresql/postgresql-8.3.3.tar.bz2. = SHA256 Checksum OK for postgresql/postgresql-8.3.3.tar.bz2. = No MD5 checksum recorded for postgresql/pg-833-icu-xx-2008-06-11.diff.gz. = No SHA256 checksum recorded for postgresql/pg-833-icu-xx-2008-06-11.diff.gz. = No suitable checksum found for postgresql/pg-833-icu-xx-2008-06-11.diff.gz. *** Error code 1 Stop in /usr/ports/databases/postgresql83-server. *** Error code 1 Stop in /usr/ports/databases/postgresql83-server. And distinfo contains: MD5 (postgresql/pg-833-icu-xx-2008-08-28.diff.gz) = 94fb6634636cd36cb5fde449d76ece65 SHA256 (postgresql/pg-833-icu-xx-2008-08-28.diff.gz) = c7d77dafe78afcf2e92567c7cdfda45dcfe41ea71efb2e326ef4f7eb66ec416b SIZE (postgresql/pg-833-icu-xx-2008-08-28.diff.gz) = 5302 Any ideas? signature.asc Description: OpenPGP digital signature
Re: Is postgresql83-server broken?
2008/8/29 Gábor Kövesdán [EMAIL PROTECTED]: Palle Girgensohn escribió: I submitted a patch yesterday the I think fixes this problem. Please try upgrading, and if it still doesn't work, email me again. I had another problem with 8.3. After installing, initdb couldn't create a new database. I needed to get a PostgreSQL server installed quickly, thus I didn't save the output... Has anyone else experienced the same? All my initdbs went fine with 8.3.x (but I didn't try it recently). The patch Palle talks about above doesn't work for me. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Interesting dependency graph for kde4
hi, I had a clean machine with 8-CURRENT with only vim-lite installed (and its dependencies). To add some useful packages, I ran pkg_add -r xorg (which went as expected) and pkg_add -r kde4 (hmmm). Adding kde4 this way pulled, among other things: mysql-server-5.0, subversion, boost and boost-python, net-snmp (daemon), cyrus-sasl, gstreamer and gstreamer-plugins. I'm not exactly complaining, just find it... curious :). ___ 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
Norberto Meijome wrote:
On Thu, 31 Jul 2008 23:38:21 +0200
Ivan Voras [EMAIL PROTECTED] 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.
Port N then won't install D2 as it already exists. The user can
rollback [N], then rollback [M+D1+D2+D3]. Trying to roll back back
[M+D1+D2+D3] before [N] will show the user a message about
dependencies.
Shouldn't you be able to request rollback [M + D1 + D2+ D3 ] , but have the
dependency of {something else not M} on D2 be detected, and therefore D2 *not*
uninstalled?
you'd end up then with M, D1, D3 removed , D2 still installed (as N needs it), and a message saying 'D2 was not removed due to existing dependencies : N '.
Yes, it's a good idea.
As a matter of fact, i don't really see why we need a transaction system to
have an option to {pkg management of choice} to uninstall {unwanted_pkg} and
all other dependencies ONLY needed by {unwanted_pkg}. Anyway, pkg_cutleaves
does part of it...but it'd be much handier, i think, to handle it @ the
uninstall time.
And since we are just wishing for things, It'd be nice to have an opportunity
to back off from a install/remove after calculating dependencies, such as that
provided by yum (it shows everything it will do and asks for confirmation
before proceeding. )
I like that in yum and have planned to include something like this. I'm
trying to decide should it be the default or not - for now, it probably
will be :)
signature.asc
Description: OpenPGP digital signature
Re: Call for comments - pkg_trans
Doug Barton wrote: Ivan Voras wrote: 2008/7/31 Doug Barton [EMAIL PROTECTED]: As I'm sure you can imagine, I would not regard any solution that says portupgrade is mandatory very favorably, and I don't think I'd be alone there. What you need to be doing here is to define the API so that whatever tool(s) the user chooses can interact with the system. No, portupgrade isn't mandatory, and it probably never will be because of ruby. It's only the most widely used and I think that any scheme that adds or changes to the behaviour of the ports infrastructure must also include portupgrade to be useful to the most users. At first glance these two statements seem contradictory, but I think what you meant in the second sentence is that for the new system to work portupgrade has to have support for it before it is rolled out. Yes :) If so, then I agree with you and would only add that authors of other ports management tools should be given adequate notice of the plans as well. Agreed. I suppose such authors read this list so will have plenty of time to catch up :) Note that, if I implement pkg_trans, any tool that doesn't know about it will, at best, generate useless single-package transactions (and at worst break the system, but I'll try hard to avoid this). Thus my concern. :) 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. Port N then won't install D2 as it already exists. Right, but D2 is still part of the transaction for N. If I roll back M but leave N installed, then roll back N, D2 should be removed (assuming for this example that D2 is not relevant to any other port). The user can rollback [N], then rollback [M+D1+D2+D3]. Trying to roll back back [M+D1+D2+D3] before [N] will show the user a message about dependencies. I seriously doubt that users would put up with that. Trying to think as a user here, I certainly would not want to be told that in order to remove a port that I don't want I first have to remove one that I do. But perhaps I'm misunderstanding you again. This is a good point and I'm glad it's brought up. I think this will work: * When user tries to roll back [M+D1+D2+D3], notice that D2 needs to stay because of N (I think I only need to notice that D2 is depended on by something that isn't in the transaction being removed) * Remove M, D1, D3 from the transaction, leave only D2 in the transaction, as if only D2 was installed in it. As you said, it would be best if D2 was then grouped with N so both get removed when N gets removed, but this is really out of scope for pkg_trans - I'm not trying to solve complex interdependencies here :) (or better said: I'm trying not to solve them...) signature.asc Description: OpenPGP digital signature
Re: Call for comments - pkg_trans
Marcin Wisnicki wrote: On Thu, 31 Jul 2008 06:25:27 +0200, Ivan Voras wrote: Hi, I apologize in advance if what I'm trying to do seems stupid or it has already existed since the Dawn of Time (i.e. when McKusick was in diapers) but I'd like your comments on this idea: http://wiki.freebsd.org/IvanVoras/PkgTransProposal Looking at your use cases I think what you are proposing is overkill. Wow, and I was afraid I'm doing an underkill here :) * Install some large group of packages, like KDE or GNOME. Don't like it, want to delete all packages installed during the operation. This could be achieved by tracking which ports were installed explicitly by user. I.e. when I type: (cd /usr/ports/x11/gnome2; make install) or pkg_add -r gnome2 It will install gnome2 along with it's dependencies but in some way mark gnome2 package as installed by user, say, by creating /var/db/pkg/ gnome2-2.22/+USER_INSTALLED or even easier, by maintaing some special unremovable dummy package that would depend on all packages installed explicitly. This has the same problems as my scheme and I'm not sure the benefits are the same. With pkg_trans, we know explicitly which packages were pulled in when, and the order in which they were pulled. * Install a newer version of postgresql, have an OMG moment and remember you need to dump the database with the old version and reaload it with the new version. Revert the install by deleting the new packages and reinstalling the old ones (i.e. undo a removal). pkg_deinstall -R posgtresql-8.4.0; pkg_add postgresql-8.3.0 Yes, with the exception that something needs to do pkg_create -b postgresql-8.3.0 before it's removed, and I don't trust myself to remember this every time :) (I want it to happen automatically) signature.asc Description: OpenPGP digital signature
Re: Call for comments - pkg_trans
Jeremy Chadwick wrote: On Thu, Jul 31, 2008 at 06:25:27AM +0200, Ivan Voras wrote: Hi, I apologize in advance if what I'm trying to do seems stupid or it has already existed since the Dawn of Time (i.e. when McKusick was in 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, pkg_delete, if they're sane) but I can't do makefiles and ruby, so if this is to work, I'll need some help :) This looks quite cool, especially the fact that it'd be tied into pkg_add and pkg_delete. By makefiles are you referring to the ports/Mk stuff, or are you referring to actual Makefiles for src/usr.sbin/pkg_install (which is ultimately where pkg_trans should go)? I'm thinking of ports/Mk - I suspect it will get hairy to add pkg_trans to the make install and similar processes on the ports. And I assume by ruby you're referring to the portupgrade tie-ins. Yes. signature.asc Description: OpenPGP digital signature
Re: Call for comments - pkg_trans
Doug Barton wrote: You have some very interesting ideas there. Not that I want to dissuade you in any way from doing this, but I would like to point out that portmaster already does some of what you're suggesting and it could fairly easily be modified to do just about all the rest of it. The two I really want the standard ways of installing and upgrading packages (make install, portinstall) to support those features. In terms of the rest of your proposal, off the top of my head the transaction IDs should probably be saved in /var/db/ports. I need to think harder about what format you could probably have a /var/db/ports/trans/ and then save the logs of the transactions as individual files by transaction ID. The wheels are spinning in my mind I don't think this is a big problem. I have an idea how to record this data. right now about how this could get hairy down the road when you install a bunch of stuff as dependencies for fooport, then you start doing upgrades on the individual dependencies the log of the transaction quickly becomes less valuable. Some thought would have to be given to exactly what the goals are, how long those logs should be valid/useful, etc. Yes, rolling back old transactions, after individual packages in them have been updated will be a problem. I see a way out of it if only portupgrade is used for the upgrading so information exists about which package is upgraded by which. signature.asc Description: OpenPGP digital signature
Call for comments - pkg_trans
Hi, I apologize in advance if what I'm trying to do seems stupid or it has already existed since the Dawn of Time (i.e. when McKusick was in 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, pkg_delete, if they're sane) but I can't do makefiles and ruby, so if this is to work, I'll need some help :) signature.asc Description: OpenPGP digital signature
Re: ports system woes
Pav Lucistnik wrote: Solution is to use tools that are available in our base system. SQLite is not. Yet :) Compared to some of the (huge) things that are maintained in the base, maintaining sqlite would be trivial :) But it's not as if the question is sqlite or bust - as OP noted, restructuring the system a bit and using better algorithms could fix many problems. The thing is - using something like sqlite is (at least for people used to SQL) much easier than rolling your own file system database (including locking and atomic ops). signature.asc Description: OpenPGP digital signature
Re: SoC Project: Ports 2.0 engine
Aryeh M. Friedman wrote: School ate any free time I had to work on ports 2.0. For this reason I would like to find some way to make it a Summer of Code project. Kip Macy has provisionally agreed to mentor it if a) it is approved by Google and FreeBSD, b) No one more qualified steps forward. Project goals (SoC portion): 1. Impliment beta quality version of the engine (see Recursive Make Considered Harmful for main points) I can't find the post with this title, but I think I get what you mean :) 2. Use the engine to build xorg and all ports it depends on 3. Creation of compatibility layer What do people think and should I proceed with submitting a application to Google? Go for it :) I'd like to suggest two of the major features that a new ports system should have: - reliability (almost in the database ACID sense; for example that no half-registered packages are created by issuing Ctrl-C in a critical moment) - parallel builds of as much as possible; at least parallel builds of independent dependencies and if possible also of ports themselves (probably by adding an opt-in flag in Makefile to signal if the port supports make -j for its build phase). The first one can be solved by rolling your own system which carefully juggles atomic operations and locks or by using an already present solution like sqlite. signature.asc Description: OpenPGP digital signature
Re: Transferring ports
On 20/03/2008, Doug Poland [EMAIL PROTECTED] wrote: Peter Pentchev wrote: On Fri, Mar 14, 2008 at 12:02:42AM +0300, Dmitry Marakasov wrote: * Ivan Voras ([EMAIL PROTECTED]) wrote: Is there a utility that would do that, and if not, does anyone have the time to write one? Would this not be an appropriate use for packages? If one creates a package for every installed port on the host system, then one simply installs the package on the target system. Yes, that's exactly what I need (the same functionality as pkg_create -b + install on the other system), only without the actual package file being created. Pipes would also be acceptable (piping the output of pkg_create from one machine to the other, etc). ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Transferring ports
Hi, I have an idea and a request for people familiar with ports pkgdb infrastructure: a utility (preferably written in C, Python or as a shell script) that would transfer *installed* ports from one system tree to the other, including their dependencies. It would transfer only some ports, specified on the command line. The details: imagine there are two or more full FreeBSD installation trees in the file system (e.g. complete jails). The utility would transfer (installed) packages from one tree to the other. The easy, brute-force way would be to generate package files (tbz) from the installed tree and then install them to the other tree, but I can't do that because of performance and disk space reasons. Is there a utility that would do that, and if not, does anyone have the time to write one? signature.asc Description: OpenPGP digital signature
Re: Transferring ports
On 13/03/2008, Dmitry Marakasov [EMAIL PROTECTED] wrote: * Ivan Voras ([EMAIL PROTECTED]) wrote: I have an idea and a request for people familiar with ports pkgdb infrastructure: a utility (preferably written in C, Python or as a shell script) that would transfer *installed* ports from one system tree to the other, including their dependencies. It would transfer only some ports, specified on the command line. There's no way to do it clearly. Not only such utility will have to deal with dependencies anyway, but also there are ports that do more than just copy files on installation (such as registering uids/gids, handling user-modified configs nicely etc.). I only need the functionality that now exists by doing pkg_create -b to create a package, and then install it. However pkg_create -b does it, that's how I need it. Actually, I've already had an idea of utility with pretty similar functionality for a long time. The utility would copy directory hierarchies recursively based on file include/exclude list, like this: The purpose is similar - creating jails out of host system in fast and easy way, possibility to strip everything unneeded (useful for secure minimal jails or flash/livecd/embedded installations of minimal size) and add something extra, like stuff from /usr/local without installing full packages in a jail, or, say, copying over additional tree of jail-specific changes (mostly stuff under /etc and /usr/local/etc). This seems like something that would be also useful to me, if it would also read pkgdb :). I need to clarify so people don't flood me with nullfs suggestions: I don't actually need it for jails, but that was the easiest way for me to describe it - I need it to set up new installations. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Preparing an Oracle Database XE port/package -- any tips ?
Rink Springer wrote: Hi, On Fri, Mar 07, 2008 at 04:36:56PM +0200, Adrian Penisoara wrote: After having to deploy an Oracle Database XE [1] installation (with Linux 32bit binaries from the official RPM package) on a production FreeBSD 6.2machine I realized it would be very much feasible to produce a FreeBSD port/package for it. I would like to know whether similar efforts have been undergoing and whether people came up with some tips tricks on this. We run Oracle XE on two FreeBSD 6.3 machines at work - we've just manually set it up, but are very interested in a port of it. We did the same as you basically - just uncompress it and move the files in place. Could any of you write a short HOWTO article, either for the official articles section or for the wiki (or both...)? signature.asc Description: OpenPGP digital signature
Re: Preparing an Oracle Database XE port/package -- any tips ?
On 07/03/2008, Adrian Penisoara [EMAIL PROTECTED] wrote: Let's not forget about the Oracle 8i installation section in the FreeBSD Handbook [1] which could surely benefit from updating (8i is desupported since a ling time). I would be glad to help (re)writing such stuff, as time permits. [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/linuxemu-oracle.html I cannot contribute since I don't use Oracle (I'm interested because running Oracle is a sort-of rite of passage - people look at an OS differently if it can run Oracle :) ), but I can do a part of the logistics - I can put the resulting text in the official wiki, find someone to convert it and add to the handbook, etc. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Porting Linux Kernel modules to FreeBSD
Bubble Reading wrote: Hi, Are there good documents/websites which discuss about porting kernel level software from Linux to FreeBSD ? This mailing list is about porting user-level applications, you might have better luck with the hackers@ and current@ mailing lists as they are both much more kernel-oriented. On the other note, Linux has a type called wait_queue_head_t. How do I port this stuff on FreeBSD ? What is the equivalent ? I don't know the Linux KPI but by the sound if it, some of these pointers might help you: http://www.freebsd.org/cgi/man.cgi?query=taskqueue http://www.freebsd.org/cgi/man.cgi?query=callout http://www.freebsd.org/cgi/man.cgi?query=queue signature.asc Description: OpenPGP digital signature
Re: Moving ports around?
Bakul Shah wrote: Can't you do something like pkg_create ... /dev/stdout | pkg_add -f -C /mnt - If compression/decompression can be removed from these steps, it would be exactly what I need. Even without it it's an improvement, thanks! signature.asc Description: OpenPGP digital signature
Re: Moving ports around?
Garrett Cooper wrote: Compressing and decompressing packages still takes an inordinate amount of time from what I've seen, so it's probably not the best idea to do. If you mean what I think you mean, I agree :) What would happen too if one or more of the config files was modified by a third-party (third-party being outside of the ports/package tools and the original FreeBSD volunteer / package maintainer)? That wouldn't work (unless you made the modifications yourself), but after that point the package becomes sort of undistributable. The only way AFAIK to circumvent that issue would be if you someone installed / created the package via a tinderbox (which is the way that it's done currently, correct?). For me, the situation is like for a tinderbox but in abstract, people might want to distribute the modified packages locally. signature.asc Description: OpenPGP digital signature
Moving ports around?
Hi Is there a canonical, re-usable way to move / rebase packages around the system, so that the package gets moved from one system directory tree to another? Example: If I have a machine with some installed packages, and another machine's root directory mounted in (e.g.) /mnt, I'd like to copy a locally installed package to /mnt, so the effect is as if the package is installed in an environment chrooted on /mnt. For now, I'm doing this the long way around, by creating a package (.tgz) file, then installing it in a chroot environment on the /mnt tree. I'd like to skip the package file creation phase and directly move the files from one location to the other, with the same effect (e.g. pre/post-install scripts, etc.). signature.asc Description: OpenPGP digital signature
Re: Moving ports around?
Pav Lucistnik wrote: Hmm, recreating a package from the installed port and installing it again in chroot() sounds pretty straightforward to me... It has the indispensable quality that it works. The downsides are the overhead in CPU consumption (compress, decompress) and disk space. signature.asc Description: OpenPGP digital signature
Re: X.org 7.2 and Radeon question
Philipp Ost wrote: Perhaps you can get the new fglrx-driver which ATi released recently I didn't know about this, but I can't find it on their drivers' section: http://ati.amd.com/support/driver.html - do you know more about this driver (e.g. where is it)? signature.asc Description: OpenPGP digital signature
Re: sed errors through portupgrade
Parv wrote: sed: 1: s|^\(@comment[: unbalanced brackets ([]) sed: 1: s|^\(@comment[: unbalanced brackets ([]) sed: 1: s|^\(@comment[: unbalanced brackets ([]) sed: 1: s|^\(@comment[: unbalanced brackets ([]) The above lines are displayed twice: once when portupgrade starts and once when it finishes. What version of portupgrade is producing the error message? What The latest non-devel version (I'm away from the machine now). command did/do you issue? portupgrade port_name. It doesn't depend on what port I'm updating. I think it might be a corruption in /var/db/pkg but I don't know which port is in error. signature.asc Description: OpenPGP digital signature
Re: [HEADS UP] ntfs-3g: better performance with libublio
Alejandro Pulver wrote: The reason AFAIK is the lack of cache for block devices, which was (re)added in FreeBSD-CURRENT (7.x). I don't think something like that cache has been added in -CURRENT. AFAIK things are still the same as in 6.x. signature.asc Description: OpenPGP digital signature
Re: qemu: kqemu not compiled?
Juergen Lock wrote: On Mon, Apr 09, 2007 at 09:51:50PM +0200, Ivan Voras wrote: Good advice, except that qemu-system-x86_64 locks up the machine hard, no autoreboot. Ouch! But only with kqemu I guess? Also, whats your guest and args to qemu-system-x86_64? Yes, it works without kqemu loaded. My guest is FreeBSD 6.2-R AMD64, I'm running it with: qemu-system-x86_64 -hda disk -cdrom 6.2-RELEASE-i386-disc1.iso -boot d -m 512 I've now tried both i386 and AMD64 guests, and both panic with kqemu, before kernel gets loaded. signature.asc Description: OpenPGP digital signature
Re: qemu: kqemu not compiled?
RW wrote: Would you expect to able to run kqemu, when the architecture is different between the host and guest? Yes, I'd expect it to translate and fixup the instructions. (Why? VMware does it :) ). The point of kqemu is that some instructions in the guest can be run natively on the host cpu. Unless there's some special support in kqemu for switching backwards and forwards between 32 and 64 mode, that's not going to work. signature.asc Description: OpenPGP digital signature
Re: qemu: kqemu not compiled?
Ivan Voras wrote: Juergen Lock wrote: On Mon, Apr 09, 2007 at 09:51:50PM +0200, Ivan Voras wrote: Good advice, except that qemu-system-x86_64 locks up the machine hard, no autoreboot. Ouch! But only with kqemu I guess? Also, whats your guest and args to qemu-system-x86_64? Yes, it works without kqemu loaded. My guest is FreeBSD 6.2-R AMD64, I'm running it with: qemu-system-x86_64 -hda disk -cdrom 6.2-RELEASE-i386-disc1.iso -boot d -m 512 I've now tried both i386 and AMD64 guests, and both panic with kqemu, before kernel gets loaded. Forgot to mention - the host is SMP. signature.asc Description: OpenPGP digital signature
Re: qemu: kqemu not compiled?
Juergen Lock wrote: In article [EMAIL PROTECTED] you write: -=-=-=-=-=- I've installed qemu 0.9 and kqemu 1.3, and I'm trying to run a i386 FreeBSD guest under amd64 FreeBSD host, but there's a problem: info kqemu command in qemu reports kqemu not compiled. But it should be - the KQEMU option is active on the port and the configure step in the port reports kqemu support: yes. Judging from the disk throughput in sysinstall (never going above e.g. 900 KB/s), it looks like it really isn't enabled. Any ideas? Use 64 bit qemu (qemu-system-x86_64) on 64 bit hosts if you want kqemu, like a real box it also runs 32 bit guests. (some still work better on 32 bit hosts tho...) Good advice, except that qemu-system-x86_64 locks up the machine hard, no autoreboot. signature.asc Description: OpenPGP digital signature
Re: default postgresql 7.4 - 8.1, OK?
Ade Lovett wrote: 8.2.x isn't really stable enough yet for Joe User to pick it up when they want postgresql support for random-port. Agreed. Also, I know it doesn't concern many users, but until it gets the ICU patch it's mostly unusable to me. :( signature.asc Description: OpenPGP digital signature
openoffice fonts - no antialiasing?
I've installed OpenOffice via package from good-day.org, version openoffice.org-SRC680_m197, and it seems somehow that font anti-aliasing doesn't work in it - both in the application user interface and on the document canvas. I've run previous versions of openoffice without problems, but I've recently updated X (to 7.2), gnome base (to whatever is latest) and xfce (to 4.4) so maybe something got misconfigured in the process. Has someone seen this behavior? Any ideas where to start looking for problems? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
no origin recorded
pkg_* programs are frequently complaining: pkg_add: package BABagntux has no origin recorded pkg_add: package BABcmagt has no origin recorded pkg_add: package BABagntux has no origin recorded pkg_add: package BABcmagt has no origin recorded pkg_add: package BABagntux has no origin recorded The problem is - yes, they don't have an origin because they're not in the ports - it's a binary-only third party backup agent, which is sort-of half-registered as a package by their install script. Any way to suppress these messages? They are making port operations hard to read. signature.asc Description: OpenPGP digital signature
Re: FreeBSD 6.1-R-p10 and PHP 5.2.0
Josh Paetzel wrote: Freshly installed FreeBSD 6.1-R-p10 box Fresh ports tree from today. php 5.2.0 installed from ports with the following extensions: # php -v PHP 5.2.0 (cli) (built: Nov 16 2006 14:47:28) (DEBUG) Copyright (c) 1997-2006 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies Segmentation fault (core dumped) I've found php to be very sensitive to trivial issues like the order of loading extensions in extensions.ini, which is just one of the reasons for its suckiness. I don't see your particular error here (both on i386 and amd64), but if is the ordering of extensions maybe you could post your extensions.ini. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.1-R-p10 and PHP 5.2.0
Mirosław Jaworski wrote: On Fri, 2006-11-17 at 11:48 +0100, Ivan Voras wrote: Josh Paetzel wrote: Freshly installed FreeBSD 6.1-R-p10 box Fresh ports tree from today. php 5.2.0 installed from ports with the following extensions: # php -v PHP 5.2.0 (cli) (built: Nov 16 2006 14:47:28) (DEBUG) Copyright (c) 1997-2006 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies Segmentation fault (core dumped) I've found php to be very sensitive to trivial issues like the order of loading extensions in extensions.ini, which is just one of the reasons for its suckiness. I don't see your particular error here (both on i386 and amd64), but if is the ordering of extensions maybe you could post your extensions.ini. Unbelievable. I left only sessions module to be loaded and it doesn't segfault. another test - i moved session to the beginning and it worked too. My session extension is also near the top: extension=bz2.so extension=session.so extension=mhash.so extension=zlib.so extension=mbstring.so extension=sockets.so extension=mcrypt.so extension=pcre.so extension=simplexml.so extension=xml.so extension=apc.so extension=sqlite.so extension=memcache.so extension=dom.so extension=iconv.so extension=mysql.so extension=gd.so extension=pgsql.so extension=ldap.so So it's probably it. Mine faulty extensions.ini was ( the result of installing php5-extensions ): -- extension=bcmath.so extension=bz2.so extension=ctype.so extension=curl.so extension=dom.so extension=exif.so extension=gd.so extension=gettext.so extension=iconv.so extension=mbstring.so extension=mcrypt.so extension=mysql.so extension=openssl.so extension=pcre.so extension=pdf.so extension=zlib.so extension=pdo.so extension=pgsql.so extension=posix.so extension=pspell.so extension=session.so extension=simplexml.so extension=soap.so extension=sqlite.so extension=tokenizer.so extension=xml.so extension=xmlreader.so extension=xmlrpc.so extension=xmlwriter.so extension=xsl.so M. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
