Firefox does not build with gcc45
Hi, It seems that shlibsign keep crashes: /home/lichray/temp/firefox/work/mozilla-2.0/obj-amd64-unknown-freebsd8.2/nss/shlibsign -v -i /home/lichray/temp/firefox/work/mozilla-2.0/obj-amd64-unknown-freebsd8.2/security/manager/../../dist/lib/libfreebl3.so moduleSpec configdir='' certPrefix='' keyPrefix='' secmod='' flags=noCertDB, noModDB Generate a DSA key pair ... Library File: /home/lichray/temp/firefox/work/mozilla-2.0/obj-amd64-unknown-freebsd8.2/nss/freebl/FreeBSD_SINGLE_SHLIB/libfreebl3.so 376337 bytes Check File: /home/lichray/temp/firefox/work/mozilla-2.0/obj-amd64-unknown-freebsd8.2/nss/freebl/FreeBSD_SINGLE_SHLIB/libfreebl3.chk Link: libfreebl3.chk hash: 20 bytes 78 d7 55 ce 21 79 d2 ff 3e f2 e8 06 a7 20 5e 96 2b d3 4b db signature: 40 bytes 5a 7b a1 8a 63 79 bd aa ba b7 17 29 26 3f b2 a7 de 1c e8 c9 40 4e 36 5e 48 e5 60 32 15 d5 d7 39 96 5f 96 2c 52 a2 61 d9 Segmentation fault (core dumped) gmake[6]: *** [/home/lichray/temp/firefox/work/mozilla-2.0/obj-amd64-unknown-freebsd8.2/security/manager/../../dist/lib/libfreebl3.chk gmake[6]: Leaving directory `/home/lichray/temp/firefox/work/mozilla-2.0/security/nss/cmd/shlibsign' ... The error is the same when I build it under /usr/ports/www. When I issue the last command by hand, it seems that there is no crash. But the core file does belong to shlibsign: ./obj-amd64-unknown-freebsd8.2/dist/lib/shlibsign.core -- Zhihao Yuan The best way to predict the future is to invent 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"
[ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
Hi all, miwi@ launched the new thing called Experimental Call For Testing, it's our turn :) 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. pkgng is a binary package manager written from scratch for FreeBSD. After a long period of technology testing, (json, tinycdb, bdb, etc) and we now have achieved to implement the basic functionnality. We would greatly approciate to have some feedback, wider testing, patching, documenting etc, before implementing the higher level features. pkgng is built on top of a new libpkg, which allow to deal with the database of installed packages, to deal with remote repositories, manage packages: creation, installation gathering informations, registering new ports. features supported are or will be : - smooth integration with bsd.port.mk (including bsd.pkg.mk line 2486) which allow to have a bsd.port.mk which deal with both pkg_install and pkgng. (done in alpha) - the register command can analyse elf files when registering a new port to discover forgotten dependencies if necessary. (done in alpha using libelf) - the register command has two mode available : when dealing with old fashion ports it just registers the package, in new mode it does everything that would have been done by pkg add when installing the package : should display messages, execute post-install, execute @exec etc. (old fashion done in the alpha) - pkg add supports two mode : the old fashion one (no real upgrade support) and new one: upgrade scripts supported. (old fashion in the alpha) - new scripts supported +PREINSTALL +POSTINSTALL, +PREDEINSTALL, +POSTDEINSTALL, +PREUPGRADE, +POSTUPGRADE as well as the old fashion scripts : +INSTALL +DEINSTALL +UPGRADE (all supported *UPGRADES aren't supported in the alpha) - new +MANIFEST (plist-like format) with new metadatas : options, arch, os version, etc. (done in the alpha) - pkgng supports checking arch of the package which means that users won't be able to install sparc64 binary package into amd64 machines. (not done yet) - a special architecture "all" allows to specify when a package can be used on every architecture. (not done yet) - @dirrm and @dirrmtry are now deprecated, pkgng can discover itself which directory has to be removed. (done in the alpha but needs love :)) - new repository (apt-like feature) (only the repository generation is done) - real support for reverse dependency (no ugly +REQUIRED_BY) (done in the alpha) - test unit (libcheck) on libpkg. (done in the alpha needs some more love) - many more 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. The alpha release come with an experimental tool "pkg2ng" to convert an existing package database to the new pkgng database format. So one can test pkgng without rebuild all its packages. One of the thing we are thinking about pkgng is to perhaps be able to provide it only as a ports (with simple script in base to boostrap/install it). That would allow pkgng to live with the ports to be able to easily integrate new features without having to support very old version of pkgng. design: pkgng is composed of : - a clean library "libpkg" that does all the work - a modern cli frontend (pkg) which accept subcommands, basically type pkg add, pkg info, pkg create etc. a dedicated subcommand exists for ports: pkg register which goal is to only supported adding to the database what is already installed. more informations can be found here: http://git.etoilebsd.net/pkgng/tree/docs/GOALS, http://git.etoilebsd.net/pkgng/tree/README http://git.etoilebsd.net/pkgng/tree/docs/TODO To download the alpha: http://git.etoilebsd.net/pkgng/snapshot/pkgng-0.1-alpha1.tar.gz Build it with debugging information: make DEBUG_FLAGS="-g -O0 -DDEBUG" Developpement site: http://git.etoilebsd.net/pkgng/ IRC chan: #pkgng@freenode Beware that pkgng is in alpha states, it can kill kittens and eat puppies, and for sure it will do it so now you are warned. regards, bapt, pgpCPBgXpoF9F.pgp Description: PGP signature
Happy Easter! Get one Sport Gadget to Enjoy Outdoor Activity, Many Gadgets as low as $1.64
If you cannot view this mail please click here ( http://a.rs-tk.com/7240-62759/priceangels.newsletter/Happy_Easter!_Get_one_Sport_Gadget_to_Enjoy_Outdoor_Activity_Many_Gadgets_as_low_as_$1.64/web.aspx ) ( http://t.rs-tk.com/t.aspx/subid/37956899/camid/62759/www.priceangels.com/index.html?home=true ) WorldWide Free Shipping Deals of the Week ( http://t.rs-tk.com/t.aspx/subid/37956899/camid/62759/www.priceangels.com/Special-DealofWeek.html ) New Arrivals ( http://t.rs-tk.com/t.aspx/subid/37956899/camid/62759/www.priceangels.com/productlist.html?newlog=true ) $0.99 Gadgets ( http://t.rs-tk.com/t.aspx/subid/37956899/camid/62759/www.priceangels.com/productlist.html?gadgets=true )My Account ( http://t.rs-tk.com/t.aspx/subid/37956899/camid/62759/www.priceangels.com/myAccount.action )Support ( http://t.rs-tk.com/t.aspx/subid/37956899/camid/62759/www.priceangels.com/CSExpress.action ) ( http://t.rs-tk.com/t.aspx/subid/37956899/camid/62759/www.priceangels.com/Life_Gadgets_Sports_Fan_t.html?page=3childtypeid=187orderby=1 ) Sport gadgets ( http://t.rs-tk.com/t.aspx/subid/37956899/camid/62759/www.priceangels.com/Life_Gadgets_Sports_Fan_t.html?page=1childtypeid=187orderby=1 ) ( http://t.rs-tk.com/t.aspx/subid/37956899/camid/62759/www.priceangels.com/Durable_Polyester_Anti-Slip_Outdoor_Full_Fingered_Gloves_Pair_Camouflage__p18438.html ) ( http://t.rs-tk.com/t.aspx/subid/37956899/camid/62759/www.priceangels.com/Military_Octagon_Shaped_Woodland_Camouflage_Hat-Green_59cm_Girth__p18841.html ) ( http://t.rs-tk.com/t.aspx/subid/37956899/camid/62759/www.priceangels.com/Environmental-Friendly_Non-Toxic_Camouflage_Mask_with_a_Elastic_Strap_p15385.html ) ( http://t.rs-tk.com/t.aspx/subid/37956899/camid/62759/www.priceangels.com/Outdoor_Sports_Polyester_CS_Protective_Goggles_with_Strap-Color_Lens_p19270.html ) Durable Polyester Anti-Slip Outdoor Full Fingered Gloves(Pair/Camouflage) ( http://t.rs-tk.com/t.aspx/subid/37956899/camid/62759/www.priceangels.com/Durable_Polyester_Anti-Slip_Outdoor_Full_Fingered_Gloves_Pair_Camouflage__p18438.html )Military Octagon Shaped Woodland Camouflage Hat-Green(59cm Girth) ( http://t.rs-tk.com/t.aspx/subid/37956899/camid/62759/www.priceangels.com/Military_Octagon_Shaped_Woodland_Camouflage_Hat-Green_59cm_Girth__p18841.html )Environmental-Friendly Non-Toxic Camouflage Mask with a Elastic Strap ( http://t.rs-tk.com/t.aspx/subid/37956899/camid/62759/www.priceangels.com/Environmental-Friendly_Non-Toxic_Camouflage_Mask_with_a_Elastic_Strap_p15385.html )Outdoor Sports Polyester CS Protective Goggles with Strap-Color Lens ( http://t.rs-tk.com/t.aspx/subid/37956899/camid/62759/www.priceangels.com/Outdoor_Sports_Polyester_CS_Protective_Goggles_with_Strap-Color_Lens_p19270.html ) $3.75 $4.51 $5.88 $5.45 ( http://t.rs-tk.com/t.aspx/subid/37956899/camid/62759/www.priceangels.com/Happy-Easter.html ) Get Free Gift Program ( http://t.rs-tk.com/t.aspx/subid/37956899/camid/62759/www.priceangels.com/Get-Free-Gift.html ) Please note that product prices and availability are subject to change. Prices and availability were accurate at the time this newsletter was sent; however, they may differ from those you see when you visit PriceAngels.com ( http://t.rs-tk.com/t.aspx/subid/37956899/camid/62759/www.benchmarkemail.com/c/l?u=142C83e=B0CDCc=1961Dt=0email=FYozfADIBnzrNRtBNYHO6HnlkRjLUbPe ). Please do not reply to this email, as we are not able to respond to messages sent to this address. Copyright 2011 PriceAngels.com. All rights reserved. Forward this email ( http://a.rs-tk.com/7240-62759/priceangels.newsletter/Happy_Easter!_Get_one_Sport_Gadget_to_Enjoy_Outdoor_Activity_Many_Gadgets_as_low_as_$1.64/forward.aspx ) Update Email & Profile ( http://s.rs-tk.com/SubscribeFormDetail.aspx?ens=/Oigl2/pjiS8poMyEdnpSg==&type=profile ) Unsubscribe ( http://s.rs-tk.com/Unsubscribe.aspx?sub=37956899&user=7240&campid=62759&type=h ) ( http://w.rs-tk.com//about.aspx?subid=37956899&campid=62759 ) ___ 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: firefox4 - drop URL not working any longer?
Freddie Cash wrote: > On Thu, Mar 24, 2011 at 11:16 AM, Heino Tiedemann > wrote: > > on all my browsers - Konqueror 3.5, previous Firefox Versions and > > even the Linux-Opera - I can drop any URL by middle click just > > somewhere into browser to load that site. > > > > On Forefox4 this is not working. > > > > Is thes geature not supported any longer? > > about:config > > Search for middle-click. Enable middle-click paste, or whatever it's > called. > > Personally, I find this to be the most annoying and useless feature of > a browser, and always disable it. +1 ___ 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"
Problem building p5-XML-Parser
===> Extracting for p5-XML-Parser-2.40 => SHA256 Checksum OK for XML-Parser-2.40.tar.gz. ===> p5-XML-Parser-2.40 depends on file: /usr/local/bin/perl5.10.1 - found ===> Patching for p5-XML-Parser-2.40 ===> p5-XML-Parser-2.40 depends on file: /usr/local/bin/perl5.10.1 - found ===> p5-XML-Parser-2.40 depends on file: /usr/local/bin/perl5.10.1 - found ===> p5-XML-Parser-2.40 depends on shared library: expat.6 - found ===> Configuring for p5-XML-Parser-2.40 Expat must be installed prior to building XML::Parser and I can't find it in the standard library directories. Install 'expat-devel' package with your OS package manager. Or you can download expat from: http://sourceforge.net/projects/expat/ If expat is installed, but in a non-standard directory, then use the following options to Makefile.PL: EXPATLIBPATH=... To set the directory in which to find libexpat EXPATINCPATH=... To set the directory in which to find expat.h For example: perl Makefile.PL EXPATLIBPATH=/home/me/lib EXPATINCPATH=/home/me/include Note that if you build against a shareable library in a non-standard location you may (on some platforms) also have to set your LD_LIBRARY_PATH environment variable at run time for perl to find the library. Checking if your kit is complete... Looks good Warning: prerequisite LWP 0 not found. Writing Makefile for XML::Parser::Expat Writing Makefile for XML::Parser ===> Building for p5-XML-Parser-2.40 cp Parser/Encodings/x-sjis-cp932.enc blib/lib/XML/Parser/Encodings/x-sjis-cp932.enc cp Parser/Encodings/iso-8859-7.enc blib/lib/XML/Parser/Encodings/iso-8859-7.enc cp Parser/Encodings/iso-8859-10.enc blib/lib/XML/Parser/Encodings/iso-8859-10.enc cp Parser/Encodings/ibm866.enc blib/lib/XML/Parser/Encodings/ibm866.enc cp Parser/Style/Tree.pm blib/lib/XML/Parser/Style/Tree.pm cp Parser/Encodings/iso-8859-9.enc blib/lib/XML/Parser/Encodings/iso-8859-9.enc cp Parser/Encodings/iso-8859-11.enc blib/lib/XML/Parser/Encodings/iso-8859-11.enc cp Parser/Encodings/x-euc-jp-unicode.enc blib/lib/XML/Parser/Encodings/x-euc-jp-unicode.enc cp Parser/Encodings/iso-8859-14.enc blib/lib/XML/Parser/Encodings/iso-8859-14.enc cp Parser/Encodings/iso-8859-1.enc blib/lib/XML/Parser/Encodings/iso-8859-1.enc cp Parser/Encodings/iso-8859-6.enc blib/lib/XML/Parser/Encodings/iso-8859-6.enc cp Parser/Encodings/big5.enc blib/lib/XML/Parser/Encodings/big5.enc cp Parser/Encodings/windows-1255.enc blib/lib/XML/Parser/Encodings/windows-1255.enc cp Parser/Encodings/iso-8859-15.enc blib/lib/XML/Parser/Encodings/iso-8859-15.enc cp Parser/Encodings/x-sjis-jdk117.enc blib/lib/XML/Parser/Encodings/x-sjis-jdk117.enc cp Parser/Encodings/x-sjis-unicode.enc blib/lib/XML/Parser/Encodings/x-sjis-unicode.enc cp Parser/LWPExternEnt.pl blib/lib/XML/Parser/LWPExternEnt.pl cp Parser/Encodings/windows-1251.enc blib/lib/XML/Parser/Encodings/windows-1251.enc cp Parser/Style/Debug.pm blib/lib/XML/Parser/Style/Debug.pm cp Parser/Encodings/iso-8859-5.enc blib/lib/XML/Parser/Encodings/iso-8859-5.enc cp Parser/Encodings/koi8-r.enc blib/lib/XML/Parser/Encodings/koi8-r.enc cp Parser/Encodings/README blib/lib/XML/Parser/Encodings/README cp Parser/Encodings/euc-kr.enc blib/lib/XML/Parser/Encodings/euc-kr.enc cp Parser/Encodings/windows-1250.enc blib/lib/XML/Parser/Encodings/windows-1250.enc cp Parser/Encodings/windows-1252.enc blib/lib/XML/Parser/Encodings/windows-1252.enc cp Parser/Encodings/Japanese_Encodings.msg blib/lib/XML/Parser/Encodings/Japanese_Encodings.msg cp Parser/Encodings/iso-8859-3.enc blib/lib/XML/Parser/Encodings/iso-8859-3.enc cp Parser/Style/Subs.pm blib/lib/XML/Parser/Style/Subs.pm cp Parser/Encodings/iso-8859-8.enc blib/lib/XML/Parser/Encodings/iso-8859-8.enc cp Parser/Encodings/iso-8859-4.enc blib/lib/XML/Parser/Encodings/iso-8859-4.enc cp Parser/Encodings/x-euc-jp-jisx0221.enc blib/lib/XML/Parser/Encodings/x-euc-jp-jisx0221.enc cp Parser/Encodings/iso-8859-13.enc blib/lib/XML/Parser/Encodings/iso-8859-13.enc cp Parser/Encodings/iso-8859-2.enc blib/lib/XML/Parser/Encodings/iso-8859-2.enc cp Parser/Style/Objects.pm blib/lib/XML/Parser/Style/Objects.pm cp Parser.pm blib/lib/XML/Parser.pm cp Parser/Encodings/x-sjis-jisx0221.enc blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc cp Parser/Style/Stream.pm blib/lib/XML/Parser/Style/Stream.pm Running Mkbootstrap for XML::Parser () chmod 644 Parser.bs rm -f blib/arch/auto/XML/Parser/Parser.so cc -shared -L/usr/local/lib -fstack-protector Parser.o -o blib/arch/auto/XML/Parser/Parser.so cc: Parser.o: No such file or directory cc: No input files specified *** Error code 1 Stop in /usr/ports/textproc/p5-XML-Parser/work/XML-Parser-2.40. *** Error code 1 Stop in /usr/ports/textproc/p5-XML-Parser. *** Error code 1 ___ 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
2011/3/25 Alexander Leidinger : > Quoting Baptiste Daroussin (from Fri, 25 Mar 2011 > 11:11:11 +0100): > >> pkgng is a binary package manager written from scratch for FreeBSD. > > I didn't had a look at it, just some comments about some parts you > explained. > >> features supported are or will be : > >> - the register command can analyse elf files when registering a new port >> to >> discover forgotten dependencies if necessary. (done in alpha using libelf) > > This will probably fail if LD_LIBRARY_PATH is used, or if we are installing > linuxulator ports. > this isn't activated by default, and if activated is only intended to work on freebsd elf files. This is done to workaround some bugguy ports not to be used in production, pkg register shows in warning in that case so that user/maintainers are warned they have something to fix. >> >> - a special architecture "all" allows to specify when a package can be >> used >> on every architecture. (not done yet) > > What if a package is able to install on a subset, e.g. the linuxulator ports > are for amd64 and i386? > No clue for that at the moment but we are open to suggestions. > What about DB corruption/loss? Do you keep the /var/db/pkg//xxx > files even with pkgng and only use the DB as a way to speed up some work (so > the DB corruption just requires to run pkg2ng), or are you lost of the DB is > lost? > Nothing is done about DB corruption/loss, I am not sure we need to do something. Maybe. Currently a filesystem corruption/loss on /var/db/pkg would do the same. but it is sqlite so we can perhaps provide a way to get compressed dump so user can periodically backup their database. regards, Bapt ___ 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
Quoting Baptiste Daroussin (from Fri, 25 Mar 2011 11:11:11 +0100): pkgng is a binary package manager written from scratch for FreeBSD. I didn't had a look at it, just some comments about some parts you explained. features supported are or will be : - the register command can analyse elf files when registering a new port to discover forgotten dependencies if necessary. (done in alpha using libelf) This will probably fail if LD_LIBRARY_PATH is used, or if we are installing linuxulator ports. - new +MANIFEST (plist-like format) with new metadatas : options, arch, os version, etc. (done in the alpha) - pkgng supports checking arch of the package which means that users won't be able to install sparc64 binary package into amd64 machines. (not done yet) - a special architecture "all" allows to specify when a package can be used on every architecture. (not done yet) What if a package is able to install on a subset, e.g. the linuxulator ports are for amd64 and i386? 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. The alpha release come with an experimental tool "pkg2ng" to convert an existing package database to the new pkgng database format. So one can test pkgng without rebuild all its packages. What about DB corruption/loss? Do you keep the /var/db/pkg//xxx files even with pkgng and only use the DB as a way to speed up some work (so the DB corruption just requires to run pkg2ng), or are you lost of the DB is lost? Bye, Alexander. -- Real computer scientists don't comment their code. The identifiers are so long they can't afford the disk space. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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
Quoting Baptiste Daroussin (from Fri, 25 Mar 2011 15:14:52 +0100): 2011/3/25 Alexander Leidinger : Quoting Baptiste Daroussin (from Fri, 25 Mar 2011 11:11:11 +0100): pkgng is a binary package manager written from scratch for FreeBSD. I didn't had a look at it, just some comments about some parts you explained. features supported are or will be : - a special architecture "all" allows to specify when a package can be used on every architecture. (not done yet) What if a package is able to install on a subset, e.g. the linuxulator ports are for amd64 and i386? No clue for that at the moment but we are open to suggestions. The suggestion is easy, allow a way to specify a set of valid architectures. What about DB corruption/loss? Do you keep the /var/db/pkg//xxx files even with pkgng and only use the DB as a way to speed up some work (so the DB corruption just requires to run pkg2ng), or are you lost of the DB is lost? Nothing is done about DB corruption/loss, I am not sure we need to do something. Maybe. I would say "for sure". Info: In Solaris 10 sqlite is used for the service managenemt framework (SMF). It is possible that the DB is corrupt in some bad situations. In this case you have to rebuild the DB (script provided, been there, had to use it). Currently a filesystem corruption/loss on /var/db/pkg would do the same. Put a corruption of /var/db/pkg/xyz-1/+REQUIRED_BY would only affect a small part, and this part could be even recovered from (pkgdb from portupgrade is able to do it). but it is sqlite so we can perhaps provide a way to get compressed dump so user can periodically backup their database. It needs to be automated. Maybe periodic daily... but maybe this is not often enough after a day of a lot of changes (think about it this way: do you want to lose a day of changes?). The current FS based DB is very robust, partly because there is redundant data, pertly because losing a file just means that the very limited subset of information is lost (and a reinstall of one port will fix it). Bye, Alexander. -- Programming is an unnatural act. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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
On Fri, Mar 25, 2011 at 2:38 PM, Alexander Leidinger wrote: > Quoting Baptiste Daroussin (from Fri, 25 Mar 2011 > 15:14:52 +0100): > >> 2011/3/25 Alexander Leidinger : >>> >>> Quoting Baptiste Daroussin (from Fri, 25 Mar 2011 >>> 11:11:11 +0100): >>> pkgng is a binary package manager written from scratch for FreeBSD. >>> >>> I didn't had a look at it, just some comments about some parts you >>> explained. >>> features supported are or will be : > - a special architecture "all" allows to specify when a package can be used on every architecture. (not done yet) >>> >>> What if a package is able to install on a subset, e.g. the linuxulator >>> ports >>> are for amd64 and i386? >>> >> >> No clue for that at the moment but we are open to suggestions. > > The suggestion is easy, allow a way to specify a set of valid architectures. That looks reasonable and easy to implement. > >>> What about DB corruption/loss? Do you keep the /var/db/pkg//xxx >>> files even with pkgng and only use the DB as a way to speed up some work >>> (so >>> the DB corruption just requires to run pkg2ng), or are you lost of the DB >>> is >>> lost? >>> >> >> Nothing is done about DB corruption/loss, I am not sure we need to do >> something. >> Maybe. > > I would say "for sure". Info: In Solaris 10 sqlite is used for the service > managenemt framework (SMF). It is possible that the DB is corrupt in some > bad situations. In this case you have to rebuild the DB (script provided, > been there, had to use it). If sqlite is properly used with transactions, it is very hard to corrupt the database. But if hardware lies to us and say that the data is on disk whereas it isnt... what can we do? Another potential problem is fsync(), but if it is broken on FreeBSD we want to fix it! BTW, the goal is to only have the database and not the flat files. If you are paranoid about power outage, use something like zfs snapshots... > >> Currently a filesystem corruption/loss on /var/db/pkg would do the same. > > Put a corruption of /var/db/pkg/xyz-1/+REQUIRED_BY would only affect a small > part, and this part could be even recovered from (pkgdb from portupgrade is > able to do it). With sqlite we have atomicity! And locks! > >> but it is sqlite so we can perhaps provide a way to get compressed >> dump so user can periodically backup their database. > > It needs to be automated. Maybe periodic daily... but maybe this is not > often enough after a day of a lot of changes (think about it this way: do > you want to lose a day of changes?). The current FS based DB is very robust, > partly because there is redundant data, pertly because losing a file just > means that the very limited subset of information is lost (and a reinstall > of one port will fix it). > > Bye, > Alexander. Regards, Julien ___ 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: firefox4 - drop URL not working any longer?
Freddie Cash wrote: > On Thu, Mar 24, 2011 at 11:16 AM, Heino Tiedemann > wrote: >> on all my browsers - Konqueror 3.5, previous Firefox Versions and even >> the Linux-Opera - I can drop any URL by middle click just somewhere into >> browser to load that site. >> >> On Forefox4 this is not working. >> >> Is thes geature not supported any longer? > > about:config > > Search for middle-click. Enable middle-click paste, or whatever it's called. I upgraded it last night. Now it is default... strange.. > Personally, I find this to be the most annoying and useless feature of > a browser, and always disable it. [x] noticed to me it is a very very often used feature ___ 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
On 2011-Mar-25, 15:03, Julien Laffaye wrote: > >>> What about DB corruption/loss? Do you keep the /var/db/pkg//xxx > >>> files even with pkgng and only use the DB as a way to speed up some work > >>> (so > >>> the DB corruption just requires to run pkg2ng), or are you lost of the DB > >>> is > >>> lost? > >>> > >> > >> Nothing is done about DB corruption/loss, I am not sure we need to do > >> something. > >> Maybe. > > > > I would say "for sure". Info: In Solaris 10 sqlite is used for the service > > managenemt framework (SMF). It is possible that the DB is corrupt in some > > bad situations. In this case you have to rebuild the DB (script provided, > > been there, had to use it). > > If sqlite is properly used with transactions, it is very hard to > corrupt the database. But if hardware lies to us and say that the data > is on disk whereas it isnt... what can we do? > Another potential problem is fsync(), but if it is broken on FreeBSD > we want to fix it! > > BTW, the goal is to only have the database and not the flat files. > If you are paranoid about power outage, use something like zfs snapshots... No need to look for strange scenarios, I'm surely going to sudo rm -f the file more sooner than later, so... maybe just save a copy? -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgp4AYvylMp4W.pgp Description: PGP signature
Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
2011/3/25 Pietro Cerutti : > On 2011-Mar-25, 15:03, Julien Laffaye wrote: >> >>> What about DB corruption/loss? Do you keep the /var/db/pkg//xxx >> >>> files even with pkgng and only use the DB as a way to speed up some work >> >>> (so >> >>> the DB corruption just requires to run pkg2ng), or are you lost of the DB >> >>> is >> >>> lost? >> >>> >> >> >> >> Nothing is done about DB corruption/loss, I am not sure we need to do >> >> something. >> >> Maybe. >> > >> > I would say "for sure". Info: In Solaris 10 sqlite is used for the service >> > managenemt framework (SMF). It is possible that the DB is corrupt in some >> > bad situations. In this case you have to rebuild the DB (script provided, >> > been there, had to use it). >> >> If sqlite is properly used with transactions, it is very hard to >> corrupt the database. But if hardware lies to us and say that the data >> is on disk whereas it isnt... what can we do? >> Another potential problem is fsync(), but if it is broken on FreeBSD >> we want to fix it! >> >> BTW, the goal is to only have the database and not the flat files. >> If you are paranoid about power outage, use something like zfs snapshots... > > No need to look for strange scenarios, I'm surely going to sudo rm -f the file > more sooner than later, so... maybe just save a copy? > > -- > Pietro Cerutti > The FreeBSD Project > g...@freebsd.org > > PGP Public Key: > http://gahr.ch/pgp > I think we can provide a periodic script activable by users (I let other decide if it has to be activated by default or not) that does a pkg backup /path/to/file/backup and xz it. because copying can be a huge. 40Mo for the database here, corresponding to 70Mo in the old format and to 600 packages. the dump xzed is only 3Mo regards, Bapt ___ 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
on 25/03/2011 17:35 Pietro Cerutti said the following: > No need to look for strange scenarios, I'm surely going to sudo rm -f the file > more sooner than later, so... maybe just save a copy? I even can rm -rf / by accident. What's your solution to this? :) P.S. one solution would be a subcase of the other -- Andriy Gapon ___ 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
On Fri, Mar 25, 2011 at 11:35 AM, Andriy Gapon wrote: > on 25/03/2011 17:35 Pietro Cerutti said the following: >> No need to look for strange scenarios, I'm surely going to sudo rm -f the >> file >> more sooner than later, so... maybe just save a copy? > > I even can rm -rf / by accident. > What's your solution to this? :) rm -rf / rm: "/" may not be removed -- Eitan Adler ___ 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"
Mplayer2
Hi guys Is someone going to port Mplayer2 (http://www.mplayer2.org/ http://www.mplayer2.org/comparison.html) to FreeBSD? Regards. ___ 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: [CFT] cpu stresser^W libreoffice 3.3.0 final
on 29/01/2011 17:36 Gary Jennejohn said the following: > After the second complaint about an input error with flex I gave up. > The suggested remedy didn't work the second time. Here's the reported > error: > > Compiling: MenuMultipleChange.idl > input in flex scanner failed Please see if commit r220004 helps you here. > dmake: Error code 2, while making > '../../../../unxfbsdx.pro/ucr/cssmozilla.db' > > --- > Oh dear - something failed during the build - sorry ! > For more help with debugging build errors, please see the section in: > http://wiki.documentfoundation.org/Development > > it seems that the error is inside 'offapi', please re-run build > inside this module to isolate the error and/or test your fix: > --- > > /bin/bash > cd > /home/garyj/misc/libreoffice/work/libreoffice-build-3.3.0.4/build/libreoffice > source ./FreeBSDAMDEnv.Set.sh > cd offapi > build > > I'm running 9.0-CURRENT amd64 installed yesterday. -- Andriy Gapon ___ 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: Mplayer2
Piotr Kudzin writes:
> Hi guys
>
> Is someone going to port Mplayer2 (http://www.mplayer2.org/
> http://www.mplayer2.org/comparison.html) to FreeBSD?
FYI, OSS4 support there doesn't work with our OSS.
http://git.mplayer2.org/mplayer2/commit/?id=91d0d3a
http://people.freebsd.org/~ariff/ports/multimedia_mplayer/patch-xzz
(different approach)
Apply below diff if you can't change volume without -softvol.
%%
diff --git a/libao2/ao_oss.c b/libao2/ao_oss.c
index 82a0dd5..198d9bf 100644
--- a/libao2/ao_oss.c
+++ b/libao2/ao_oss.c
@@ -153,7 +153,7 @@ static int prepause_space;
static const char *oss_mixer_device = PATH_DEV_MIXER;
static int oss_mixer_channel = SOUND_MIXER_PCM;
-#ifdef SNDCTL_DSP_GETPLAYVOL
+#if 0
static int volume_oss4(ao_control_vol_t *vol, int cmd) {
int v;
@@ -201,7 +201,7 @@ static int control(int cmd,void *arg){
ao_control_vol_t *vol = (ao_control_vol_t *)arg;
int fd, v, devs;
-#ifdef SNDCTL_DSP_GETPLAYVOL
+#if 0
// Try OSS4 first
if (volume_oss4(vol, cmd) == CONTROL_OK)
return CONTROL_OK;
%%
___
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
On Fri, Mar 25, 2011 at 11:54:35AM -0500, Eitan Adler wrote: > On Fri, Mar 25, 2011 at 11:35 AM, Andriy Gapon wrote: > > on 25/03/2011 17:35 Pietro Cerutti said the following: > >> No need to look for strange scenarios, I'm surely going to sudo rm -f the > >> file > >> more sooner than later, so... maybe just save a copy? > > > > I even can rm -rf / by accident. > > What's your solution to this? :) > > rm -rf / > rm: "/" may not be removed referring to the CVS, this should improve the approach. cd /tmp rm -rf ../* ymmv -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgp5D40nqAsVs.pgp Description: PGP signature
Re: firefox4 - drop URL not working any longer?
Heino Tiedemann wrote: > on all my browsers - Konqueror 3.5, previous Firefox Versions and even > the Linux-Opera - I can drop any URL by middle click just somewhere into > browser to load that site. > > On Forefox4 this is not working. Yes, it is. However, you can't omit a leading "http://"; any longer. Pasting an URL like www.freebsd.org/about.html will not work. -- Christian "naddy" Weisgerber na...@mips.inka.de ___ 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"
hyphen in PORTNAME... still bad?
Hi! Anyone remember the reason behind this portlint warning and whether it can be ignored? (like several ports seem to do, even high-profile ones like boost-libs or docbook-xml...) WARN: Makefile: using hyphen in PORTNAME. consider using PKGNAMEPREFIX and/or PKGNAMESUFFIX. I'm sure there must have been a reason for the warning, but is it still valid? And in case it matters, my specific case would be vdr plugin ports, up to now I had my shars install them as vdr_plugin_foo- because of the warning, but since I still have the port dirs named vdr-plugin-foo there was concern about this being an inconsisteny, and also I somehow like the names with hyphens better. :) Or should I really set PKGNAMEPREFIX= vdr-plugin- like the warning suggests? Most of the plugin distfiles are named like vdr-foo-.tgz in case it matters, example: vdr-streamdev-0.5.1.tgz for vdr-plugin-streamdev. Thanx, Juergen ___ 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: Mplayer2
Thanks for patches Pan Tsu, i'll try them out as soon i'll put FBSD on
this box.
PS. Are You working on official prot of Mplayer2 for FBSD ports tree ??
2011/3/25 Pan Tsu :
> Piotr Kudzin writes:
>
>> Hi guys
>>
>> Is someone going to port Mplayer2 (http://www.mplayer2.org/
>> http://www.mplayer2.org/comparison.html) to FreeBSD?
>
> FYI, OSS4 support there doesn't work with our OSS.
>
> http://git.mplayer2.org/mplayer2/commit/?id=91d0d3a
> http://people.freebsd.org/~ariff/ports/multimedia_mplayer/patch-xzz
> (different approach)
>
> Apply below diff if you can't change volume without -softvol.
>
> %%
> diff --git a/libao2/ao_oss.c b/libao2/ao_oss.c
> index 82a0dd5..198d9bf 100644
> --- a/libao2/ao_oss.c
> +++ b/libao2/ao_oss.c
> @@ -153,7 +153,7 @@ static int prepause_space;
> static const char *oss_mixer_device = PATH_DEV_MIXER;
> static int oss_mixer_channel = SOUND_MIXER_PCM;
>
> -#ifdef SNDCTL_DSP_GETPLAYVOL
> +#if 0
> static int volume_oss4(ao_control_vol_t *vol, int cmd) {
> int v;
>
> @@ -201,7 +201,7 @@ static int control(int cmd,void *arg){
> ao_control_vol_t *vol = (ao_control_vol_t *)arg;
> int fd, v, devs;
>
> -#ifdef SNDCTL_DSP_GETPLAYVOL
> +#if 0
> // Try OSS4 first
> if (volume_oss4(vol, cmd) == CONTROL_OK)
> return CONTROL_OK;
> %%
>
___
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
On Fri, 25 Mar 2011 16:35:21 +0100 Pietro Cerutti wrote: > On 2011-Mar-25, 15:03, Julien Laffaye wrote: > > >>> What about DB corruption/loss? Do you keep > > >>> the /var/db/pkg//xxx files even with pkgng and only > > >>> use the DB as a way to speed up some work (so > > >>> the DB corruption just requires to run pkg2ng), or are you lost > > >>> of the DB is > > >>> lost? > > >>> > > >> > > >> Nothing is done about DB corruption/loss, I am not sure we need > > >> to do something. > > >> Maybe. > > > > > > I would say "for sure". Info: In Solaris 10 sqlite is used for > > > the service managenemt framework (SMF). It is possible that the > > > DB is corrupt in some bad situations. In this case you have to > > > rebuild the DB (script provided, been there, had to use it). > > > > If sqlite is properly used with transactions, it is very hard to > > corrupt the database. But if hardware lies to us and say that the And as I told above, I even had such a case (more than once), and the hardware was not buggy. What do you want to tell in this case, "life sucks, reinstall everything"? > > data is on disk whereas it isnt... what can we do? Sometimes you have to stay with broken hardware. > > Another potential problem is fsync(), but if it is broken on FreeBSD > > we want to fix it! > > > > BTW, the goal is to only have the database and not the flat files. > > If you are paranoid about power outage, use something like zfs > > snapshots... There are more FS than only ZFS (personally I use ZFS, and I have snapshots, but this is not a good solution for this problem). As I told already, if it isn't automatic, nearly nobody will use it. And the package management stuff has to be automatic, no freshman will think about setting up a snapshot script when he starts to use packages/ports. > No need to look for strange scenarios, I'm surely going to sudo rm -f > the file more sooner than later, so... maybe just save a copy? A copy or two would be enough, but it has to be done automatically, and once a day is not enough. A copy after each X modifications maybe (for suitable definitions of X and 'modifications'). Bye, Alexander. ___ 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: hyphen in PORTNAME... still bad?
> Anyone remember the reason behind this portlint warning and whether > it can be ignored? (like several ports seem to do, even high-profile > ones like boost-libs or docbook-xml...) > > WARN: Makefile: using hyphen in PORTNAME. consider using PKGNAMEPREFIX > and/or PKGNAMESUFFIX. > > I'm sure there must have been a reason for the warning, but is it > still valid? The warning is talking about things such as the p5- prefix and the -devel suffix. If your port name legitimately has a hyphen in it then nothing should break. The warning is still valid but in this case could safely be ignored. > Or should I really set PKGNAMEPREFIX= vdr-plugin- like the > warning suggests? It is up to you, but I would leave it in the PORTNAME. I would use PKGNAMEPREFIX for modules that don't contain the prefix in their name (see mod_* that uses the apache prefix for examples). -- Eitan Adler ___ 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
As far as package managers go, yum, which is used widely, uses SQLite. -- Peace cannot be achieved through violence, it can only be attained through understanding. ___ 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
On Fri, Mar 25, 2011 at 1:14 PM, Alexander Leidinger wrote: > On Fri, 25 Mar 2011 16:35:21 +0100 Pietro Cerutti > wrote: > >> On 2011-Mar-25, 15:03, Julien Laffaye wrote: >> > >>> What about DB corruption/loss? Do you keep >> > >>> the /var/db/pkg//xxx files even with pkgng and only >> > >>> use the DB as a way to speed up some work (so >> > >>> the DB corruption just requires to run pkg2ng), or are you lost >> > >>> of the DB is >> > >>> lost? >> > >>> >> > >> >> > >> Nothing is done about DB corruption/loss, I am not sure we need >> > >> to do something. >> > >> Maybe. >> > > >> > > I would say "for sure". Info: In Solaris 10 sqlite is used for >> > > the service managenemt framework (SMF). It is possible that the >> > > DB is corrupt in some bad situations. In this case you have to >> > > rebuild the DB (script provided, been there, had to use it). >> > >> > If sqlite is properly used with transactions, it is very hard to >> > corrupt the database. But if hardware lies to us and say that the > > And as I told above, I even had such a case (more than once), and the > hardware was not buggy. What do you want to tell in this case, "life > sucks, reinstall everything"? If you use binary packages, pulling down everything should be trivial, fast, and easy to install. If you're using ports, well then things are going to be slow as expected. >> > data is on disk whereas it isnt... what can we do? > > Sometimes you have to stay with broken hardware. Sometimes you have to go buy new parts? Playing with broken hardware is like playing with fire -- sometimes you'll get burned if it goes out of commission during critical operations. I would be more concerned about overall system operation than having a packaging system that can handle all error conditions that should be rightfully handled by various kernel subsystems. If the kernel's doing it's job, then the packaging manager can do its job as well. >> > Another potential problem is fsync(), but if it is broken on FreeBSD >> > we want to fix it! >> > >> > BTW, the goal is to only have the database and not the flat files. >> > If you are paranoid about power outage, use something like zfs >> > snapshots... > > There are more FS than only ZFS (personally I use ZFS, and I have > snapshots, but this is not a good solution for this problem). A lot of filesystems feature snapshot'ing, including UFS. If you aren't smart enough to back up your data you're toast if the data is gone. I would be more concerned about the program getting killed, not getting properly cleaned up, etc as this is something that the package manager frontend (or whatever the official name is) should catch and fail gracefully with. Things need to follow an ACID methodology and be recoverable in the event that it can't be ACID, or it's no better than pkg_install/ports currently is if it's caught in the middle of a critical operation today installing or removing software. If SQLite can't deliver this level of ACID-like capability, then pkg_install needs to be redesigned. > As I told already, if it isn't automatic, nearly nobody will use it. > And the package management stuff has to be automatic, no freshman will > think about setting up a snapshot script when he starts to use > packages/ports. I'd just provide an export command to print out a (JSON?) version of the information, and move on. None of the other major packaging systems out there that I know of use flat files for this data, and I would rather not make it automatic because it's an unnecessary performance hit. If the user feels the need for backing up his/her data they will. If not, they're SoL in the event of a crash. >> No need to look for strange scenarios, I'm surely going to sudo rm -f >> the file more sooner than later, so... maybe just save a copy? > > A copy or two would be enough, but it has to be done automatically, and > once a day is not enough. A copy after each X modifications maybe > (for suitable definitions of X and 'modifications'). Please see my comment above. There's no reason why this belongs in a packaging system (you can add it as an external tool, but the point is to avoid architectural mistakes that leaked into the old pkg_install over the period of 10 years or so). Thanks, -Garrett PS Sorry for being so hardnosed on this, but I want something that's fast and correct, instead of something bloated, slow, half-baked, harder to test, etc. pkg_install gets executed enough times during a port upgrade that having something more streamlined for most usecases is the only way to go, and there's enough code that doesn't get executed on a regular basis that has no business being in pkg_install. ___ 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: [CFT] A new mplayer and mencoder
Dear all, thanks to all of you who have provided feedback and patches for the new mplayer/mencoder snapshot. With the exception of Christian's lavcac3enc problem (sorry, didn't have time yet to dig deep enough) everything I am currently aware of is addressed in this new tarball: http://www.rrr.de/~riggs/mplayer/m20110325.tar.bz2 Thank you in advance, Riggs ___ 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
2011/3/25 Yuri : > On 03/25/2011 03:11, Baptiste Daroussin wrote: >> >> 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. >> >> pkgng is a binary package manager written from scratch for FreeBSD. >> > > How does it relate to portmaster and portupgrade packages, which both have > (or include) supposedly the same functionality? > > Yuri > both have to be adapted, portupgrade throught maybe some ruby bindings to libpkg, portmaster by patching it to use pkg frontend instead of pkg_* tools (as I did for the ports (see ports/bsd.pkgng.mk in the git tree) regards, Bapt ___ 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
On Fri, 25 Mar 2011 13:47:13 -0700 Garrett Cooper wrote: > On Fri, Mar 25, 2011 at 1:14 PM, Alexander Leidinger > wrote: > > On Fri, 25 Mar 2011 16:35:21 +0100 Pietro Cerutti > > wrote: > > > >> On 2011-Mar-25, 15:03, Julien Laffaye wrote: > >> > >>> What about DB corruption/loss? Do you keep > >> > >>> the /var/db/pkg//xxx files even with pkgng and only > >> > >>> use the DB as a way to speed up some work (so > >> > >>> the DB corruption just requires to run pkg2ng), or are you > >> > >>> lost of the DB is > >> > >>> lost? > >> > >>> > >> > >> > >> > >> Nothing is done about DB corruption/loss, I am not sure we > >> > >> need to do something. > >> > >> Maybe. > >> > > > >> > > I would say "for sure". Info: In Solaris 10 sqlite is used for > >> > > the service managenemt framework (SMF). It is possible that the > >> > > DB is corrupt in some bad situations. In this case you have to > >> > > rebuild the DB (script provided, been there, had to use it). > >> > > >> > If sqlite is properly used with transactions, it is very hard to > >> > corrupt the database. But if hardware lies to us and say that the > > > > And as I told above, I even had such a case (more than once), and > > the hardware was not buggy. What do you want to tell in this case, > > "life sucks, reinstall everything"? > > If you use binary packages, pulling down everything should be trivial, > fast, and easy to install. If you're using ports, well then things are > going to be slow as expected. And if there is a fast way to cut down the slow part... why not? > >> > data is on disk whereas it isnt... what can we do? > > > > Sometimes you have to stay with broken hardware. > > Sometimes you have to go buy new parts? Yes, but if we talk e.g. about aging hardware, having the luck to get hit directly in the parts which hurt is not nice. You want to have the time to find a suitable replacement. > Playing with broken hardware is like playing with fire -- sometimes > you'll get burned if it goes out of commission during critical > operations. I would be more concerned about overall system operation > than having a packaging system that can handle all error conditions > that should be rightfully handled by various kernel subsystems. If the > kernel's doing it's job, then the packaging manager can do its job as > well. You know that the world is not an ideal one. Shit happens and Murphy visits you. > >> > Another potential problem is fsync(), but if it is broken on > >> > FreeBSD we want to fix it! > >> > > >> > BTW, the goal is to only have the database and not the flat > >> > files. If you are paranoid about power outage, use something > >> > like zfs snapshots... > > > > There are more FS than only ZFS (personally I use ZFS, and I have > > snapshots, but this is not a good solution for this problem). > > A lot of filesystems feature snapshot'ing, including UFS. If you > aren't smart enough to back up your data you're toast if the data is > gone. So... why do we have /var/backups/master.passwd.bak then? To make life easy. > I would be more concerned about the program getting killed, not > getting properly cleaned up, etc as this is something that the package > manager frontend (or whatever the official name is) should catch and > fail gracefully with. Things need to follow an ACID methodology and be > recoverable in the event that it can't be ACID, or it's no better than > pkg_install/ports currently is if it's caught in the middle of a > critical operation today installing or removing software. I agree. > If SQLite can't deliver this level of ACID-like capability, then > pkg_install needs to be redesigned. AFAIK it can. > > As I told already, if it isn't automatic, nearly nobody will use it. > > And the package management stuff has to be automatic, no freshman > > will think about setting up a snapshot script when he starts to use > > packages/ports. > > I'd just provide an export command to print out a (JSON?) > version of the information, and move on. None of the other major > packaging systems out there that I know of use flat files for this > data, and I would rather not make it automatic because it's an > unnecessary performance hit. If the user feels the need for backing up > his/her data they will. If not, they're SoL in the event of a crash. - It does not need to be done with every change. - You do not know if it is a performance hit or not, we do not have numbers. - If making an automatic export after X modifications is not expensive, I say: why not? It would make more easy in case of fire. > >> No need to look for strange scenarios, I'm surely going to sudo rm > >> -f the file more sooner than later, so... maybe just save a copy? > > > > A copy or two would be enough, but it has to be done automatically, > > and once a day is not enough. A copy after each X modifications > > maybe (for suitable definitions of X and 'modifications'). > > Please see my comment above. There's no reason why this belongs in a > packag
Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On 03/25/2011 03:11, Baptiste Daroussin wrote: 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. pkgng is a binary package manager written from scratch for FreeBSD. How does it relate to portmaster and portupgrade packages, which both have (or include) supposedly the same functionality? Yuri ___ 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"
Building for libofa-0.9.3_6 fails
I got this problem with building libofa-0.9.3_6 What can I do to solve it? -- ===> Building for libofa-0.9.3_6 make all-recursive Making all in include Making all in ofa1 Making all in lib Making all in JAMA Making all in AFLIB if /bin/sh /usr/local/bin/libtool --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -O2 -pipe -fno-strict-aliasing -MT fftlibw3_op.lo -MD -MP -MF ".deps/fftlibw3_op.Tpo" -c -o fftlibw3_op.lo fftlibw3_op.cpp; then mv -f ".deps/fftlibw3_op.Tpo" ".deps/fftlibw3_op.Plo"; else rm -f ".deps/fftlibw3_op.Tpo"; exit 1; fi if /bin/sh /usr/local/bin/libtool --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -O2 -pipe -fno-strict-aliasing -MT fft_op.lo -MD -MP -MF ".deps/fft_op.Tpo" -c -o fft_op.lo fft_op.cpp; then mv -f ".deps/fft_op.Tpo" ".deps/fft_op.Plo"; else rm -f ".deps/fft_op.Tpo"; exit 1; fi libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -O2 -pipe -fno-strict-aliasing -MT fft_op.lo -MD -MP -MF .deps/fft_op.Tpo -c fft_op.cpp -fPIC -DPIC -o .libs/fft_op.o In file included from fft_op.h:23, libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -O2 -pipe -fno-strict-aliasing -MT fftlibw3_op.lo -MD -MP -MF .deps/fftlibw3_op.Tpo -c fftlibw3_op.cpp -fPIC -DPIC -o .libs/fftlibw3_op.o In file included from fftlibw3_op.cpp:19: fftlib_op.h:35:19: error: fftw3.h: No such file or directory In file included from fftlibw3_op.cpp:19: fftlib_op.h:47: error: 'fftw_plan' does not name a type fftlib_op.h: In constructor 'FFTLib_op::FFTLib_op()': fftlib_op.h:39: error: 'PlanF' was not declared in this scope fftlibw3_op.cpp: In member function 'void FFTLib_op::Initialize(int, bool)': fftlibw3_op.cpp:26: error: 'FFTW_MEASURE' was not declared in this scope fftlibw3_op.cpp:28: error: 'FFTW_ESTIMATE' was not declared in this scope fftlibw3_op.cpp: In member function 'void FFTLib_op::Destroy()': fftlibw3_op.cpp:35: error: 'PlanF' was not declared in this scope fftlibw3_op.cpp:35: error: 'fftw_destroy_plan' was not declared in this scope from fft_op.cpp:17: fftlib_op.h:35:19: error: fftw3.h: No such file or directory fftlibw3_op.cpp: In member function 'void FFTLib_op::SetSize(int, bool, double*, double*)': fftlibw3_op.cpp:42: error: 'FFTW_MEASURE' was not declared in this scope fftlibw3_op.cpp:44: error: 'FFTW_ESTIMATE' was not declared in this scope fftlibw3_op.cpp:46: error: 'PlanF' was not declared in this scope fftlibw3_op.cpp:48: error: 'fftw_destroy_plan' was not declared in this scope fftlibw3_op.cpp:52: error: 'PlanF' was not declared in this scope fftlibw3_op.cpp:52: error: 'FFTW_R2HC' was not declared in this scope fftlibw3_op.cpp:52: error: 'fftw_plan_r2r_1d' was not declared in this scope fftlibw3_op.cpp: In member function 'void FFTLib_op::ComputeFrame(int, double*, double*)': fftlibw3_op.cpp:58: error: 'PlanF' was not declared in this scope fftlibw3_op.cpp:58: error: 'fftw_execute' was not declared in this scope In file included from fft_op.h:23, from fft_op.cpp:17: fftlib_op.h:47: error: 'fftw_plan' does not name a type fftlib_op.h: In constructor 'FFTLib_op::FFTLib_op()': fftlib_op.h:39: error: 'PlanF' was not declared in this scope *** Error code 1 *** Error code 1 2 errors *** Error code 1 1 error *** Error code 1 1 error *** Error code 2 1 error *** Error code 1 Stop in /usr/ports/audio/libofa. *** Error code 1 Stop in /usr/ports/audio/libofa. ___ 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: Building for libofa-0.9.3_6 fails
Leslie Jensen ha scritto:
I got this problem with building libofa-0.9.3_6
What can I do to solve it?
Set:
CPPFLAGS+= -I${LOCALBASE}/include
in the port's Makefile.
--
Alex Dupre
___
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: Building for libofa-0.9.3_6 fails
On 2011-03-25 23:02, Alex Dupre wrote:
Leslie Jensen ha scritto:
I got this problem with building libofa-0.9.3_6
What can I do to solve it?
Set:
CPPFLAGS+= -I${LOCALBASE}/include
in the port's Makefile.
Thank you :-)
Problem fixed.
___
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: Building for libofa-0.9.3_6 fails
Alex Dupre wrote:
> Leslie Jensen ha scritto:
>> I got this problem with building libofa-0.9.3_6
>>
>> What can I do to solve it?
>
> Set:
>
> CPPFLAGS+=-I${LOCALBASE}/include
>
> in the port's Makefile.
shouldn't it be put into that file by maintainer?
Heino
___
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
On Fri, 25 Mar 2011 11:11:11 +0100, Baptiste Daroussin wrote: > pkgng is a binary package manager written from scratch for FreeBSD. > Fantastic! I know it is quite too early but I already have one feature request ;) Perhaps it could be added to the TODO as a post-1.0 goal. = Generic extraction filters = Allow registration of custom filters that can alter/exclude/add? files during package extraction (installation). Examples of possible filters: - strip debug info - exclude development files (headers, static libs) - exclude unused translations - exclude documentation (all or just unknown languages) - generic glob/regex path filters - optional file groups defined in package (install time OPTIONS) ? Some sort of configuration mechanism with list of enabled filters and their options (like a list of languages to keep). Most of this can be implemented as a simple glob/regex matching but there are edge cases where packages have some non-standard layout or have to keep certain file in which case a package metadata should contain a list of exclusions/additions from/to above categories. Package manager should register only actually installed files but list of alterations should be also kept somewhere in database. What do you think ? ___ 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: Building for libofa-0.9.3_6 fails
On Fri, Mar 25, 2011 at 5:56 PM, Heino Tiedemann
wrote:
> Alex Dupre wrote:
>
>> Leslie Jensen ha scritto:
>>> I got this problem with building libofa-0.9.3_6
>>>
>>> What can I do to solve it?
>>
>> Set:
>>
>> CPPFLAGS+= -I${LOCALBASE}/include
>>
>> in the port's Makefile.
>
> shouldn't it be put into that file by maintainer?
It should.
>
> Heino
>
> ___
> 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"
>
--
Zhihao Yuan
The best way to predict the future is to invent 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"
