Re: Skype 4.0
Robert Simmons rsimmo...@gmail.com wrote .. On Fri, Jun 15, 2012 at 9:59 PM, Darren Pilgrim list_free...@bluerosetech.com wrote: On 2012-06-15 14:25, Robert Simmons wrote: On Fri, Jun 15, 2012 at 5:11 PM, Rich Neeser.ne...@gmail.com wrote: I just wish skype would get off their buts and make a bsd version. time to break code and make a opensource version That's not the answer. Really, everyone needs to move away from Skype altogether. Use Blink. It is a superior client and it uses SIP rather than Skype's network. Making a FreeBSD port of it has been on my list of things to do for quite a while, I just haven't had the time. Skype supports video calls. According to AG Projects' website, Blink is a VoIP app with IM features added, no video. Is this not the case? I dislike video, so I have never even looked for that feature, but now that I'm looking, no it doesn't support video. I was curious, so I googled alternatives to Blink and I ran across Linphone. Has anyone used this? It exists in the FreeBSD ports collection, but is a few versions behind the current stable version from the project's website. ___ 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 dude like since MS bought it they haven't even released any non-win32 version. i agree, a different alternative to skype is better, and get your contacts to join up with that. -- Waitman Gobble San Jose California USA ___ 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: Skype 4.0
On Sat, Jun 16, 2012 at 2:02 AM, Waitman Gobble uzi...@da3m0n8t3r.com wrote: dude like since MS bought it they haven't even released any non-win32 version. i agree, a different alternative to skype is better, and get your contacts to join up with that. Huh? New in this version 4.0: http://www.skype.com/intl/en-us/get-skype/on-your-computer/linux/ ___ 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: Skype 4.0
On Fri, Jun 15, 2012 at 8:36 PM, Robert Simmons rsimmo...@gmail.com wrote: On Fri, Jun 15, 2012 at 9:59 PM, Darren Pilgrim list_free...@bluerosetech.com wrote: On 2012-06-15 14:25, Robert Simmons wrote: On Fri, Jun 15, 2012 at 5:11 PM, Rich Neeser.ne...@gmail.com wrote: I just wish skype would get off their buts and make a bsd version. time to break code and make a opensource version That's not the answer. Really, everyone needs to move away from Skype altogether. Use Blink. It is a superior client and it uses SIP rather than Skype's network. Making a FreeBSD port of it has been on my list of things to do for quite a while, I just haven't had the time. Skype supports video calls. According to AG Projects' website, Blink is a VoIP app with IM features added, no video. Is this not the case? I dislike video, so I have never even looked for that feature, but now that I'm looking, no it doesn't support video. I was curious, so I googled alternatives to Blink and I ran across Linphone. Has anyone used this? It exists in the FreeBSD ports collection, but is a few versions behind the current stable version from the project's website. You might look at ekiga. It is in ports and a standard part of Gnome. It does sip and also claims to support H.323 conferencing, but I have not had much success making it work with our H.323 system. I will admit that I have not tried in a while, though. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: Skype 4.0
On Sat, Jun 16, 2012 at 2:12 AM, Kevin Oberman kob6...@gmail.com wrote: You might look at ekiga. It is in ports and a standard part of Gnome. It does sip and also claims to support H.323 conferencing, but I have not had much success making it work with our H.323 system. I will admit that I have not tried in a while, though. I remember looking at Ekiga when I was trying out different SIP clients last year, and what turned me off is the gnome thing. I am a KDE user, so Blink being a qt application means it is a KDE camp application. ___ 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: Skype 4.0
On Fri, Jun 15, 2012 at 11:17 PM, Robert Simmons rsimmo...@gmail.com wrote: On Sat, Jun 16, 2012 at 2:12 AM, Kevin Oberman kob6...@gmail.com wrote: You might look at ekiga. It is in ports and a standard part of Gnome. It does sip and also claims to support H.323 conferencing, but I have not had much success making it work with our H.323 system. I will admit that I have not tried in a while, though. I remember looking at Ekiga when I was trying out different SIP clients last year, and what turned me off is the gnome thing. I am a KDE user, so Blink being a qt application means it is a KDE camp application. Fair enough. I use gnome, but am never going to Gnome3, so I may be running KDE before long. If you run gnome, try ekiga. If you use KDE (and don't need video), go with blink. Both support open standards. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: Skype 4.0
El día Saturday, June 16, 2012 a las 02:17:53AM -0400, Robert Simmons escribió: On Sat, Jun 16, 2012 at 2:12 AM, Kevin Oberman kob6...@gmail.com wrote: You might look at ekiga. It is in ports and a standard part of Gnome. It does sip and also claims to support H.323 conferencing, but I have not had much success making it work with our H.323 system. I will admit that I have not tried in a while, though. I remember looking at Ekiga when I was trying out different SIP clients last year, and what turned me off is the gnome thing. I am a KDE user, so Blink being a qt application means it is a KDE camp application. Ekiga can be compiled out of the sources in svn and git and runs fine in KDE: http://wiki.ekiga.org/index.php/Compile_your_own_SVN_version_of_Ekiga_on_FreeBSD matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 ___ 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: Mk macros print/texinfo/distinfo variant SHA256 SIZE
Hi johans at FreeBSD.org
cc ports@
A 9.0-RELEASE ports fails on
cd print/texinfo ; make fetch
unless one imports newer values from current,
...
So how best to modify Makefile to not break on size sha256 of
some but not all files ?
The question can't be unique to this port,
...
Thoughts ?
It isn't unique to this port. We already have such a construct:
IGNOREFILES, (See ports/Mk/bsd.port.mk, or
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-checksum.html
.) Its use is discouraged because of security concerns. It would
_not_ be wise to
ignore checksums in the case of the texinfo sources -- instead, the
maintainer can simply place copies of the unversioned sources in a
separate, fully-versioned subdirectory on his mirror (e.g.,
${PORTVERSION} rather than ${PORTVERSION:E}), so that they would be
available there after they had been supplanted by newer versions on
the upstream mirrors. The versioned sources could reside in an
unversioned or partly-versioned subdirectory, to avoid unnecessary
copies. The maintainer probably knows how to do this; it is described
at:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-distfiles.html#PORTING-MASTER-SITES-N
b.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD not so free anymore ? Long live FreeBSD...
On Jun 15, 2012 10:13 PM, Jerry je...@seibercom.net wrote: On Fri, 15 Jun 2012 19:12:58 +0100 Chris Rees articulated: On 15 June 2012 18:53, Etienne Robillard animelo...@gmail.com wrote: On 06/15/2012 01:08 PM, Jerry wrote: Skype 4.0 for Linux is now available. Is there any possibility of getting it ported to FreeBSD? The latest version in ports is only 2.x. Why not? Thinking FreeBSD could become immune to remote exploits is absurd. So without much efforts I can guess ports like Skype will become more widespread now that FreeBSD has gived up on network security, preferring to announce critical security vulnerabilities once the exploit has been confirmed without any warnings. A good reason to stop using this bloated OS if you ask me and use something more respectful to their users base relaying on STABLE for stability reasons... New versions of Skype require ALSA. This is at their insistence. So, are you implying that ALSA (Advanced Linux Sound Architecture) is never going to happen on a FreeBSD system? It is unnecessary. Chris ___ 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
Emacs?
Hi, emacs 24 final is out There isn't an emacs 24 final in editors/emacs neither in editors/emacs-devel is there someone working on that? 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: Mk macros print/texinfo/distinfo variant SHA256 SIZE
Hi Julian, Julian H. Stacey wrote: A 9.0-RELEASE ports fails on cd print/texinfo ; make fetch unless one imports newer values from current, I copied the versions used by this port to my own server to prevent this failure, specificially for the case that the primary sources updates the files. The old files should still be retrievable from ftp.stack.nl if they are modified on the GNU servers. Maybe this secondary server was temporarily unavailable? That said, it is generally a good idea to keep your ports tree up-to-date, rather than to stick with a static snapshort ports tree from the release date. Regards, Johan pgpMFartKGOW8.pgp Description: PGP signature
kmail since upgrade
Hi I followed UPDATING instructions and deleted -r /akonadi immediately before running portupgrade -a which resulted in an upgrade to kde4 8.4. Now I seem to have a problem with kmail which when launched gives: Error kmail kmail encountered a fatal error and will terminate now. The error was: Failed to fetch resource collection. There seems to be no way to ignore the termination and set up kmail to read and access existing configuration data. This is for me a serious issue having many thousands of carefully catalogued emails. How do I set about recovery? The mails seem to be there - a I can access them via pop server onto another machine. But the indexing and cataloguing data does not move across. In the meantime I am using mail via the pop serverMS$ outlook - yuck Thanks in advance David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD not so free anymore ? Long live FreeBSD...
On Sat, 16 Jun 2012 12:00:47 + (UTC) Jerry je...@seibercom.net wrote: So, are you implying that ALSA (Advanced Linux Sound Architecture) is never going to happen on a FreeBSD system? Our OSS sound subsystem works (and allows multiple access) without twenty different sound servers, mixers, shim layers and much faffing about, which is how we like it. So no, it's very unlikely we the users are going to put up with some putz wanting to swap that for something that only works when the planets are in the correct alignment after the use of some mystical incantation and the ritual sacrifice of a gnu just to get Skype (which is now owned by MS and is also now a conduit for yet more advertising) going. Sound is one of the things FreeBSD gets very right and most reasonably portable applications are just fine with our implementation of it. There's a compat port for those who want/need the ALSA API. -- Matt Dawson MTD15-RIPE GW0VNR signature.asc Description: PGP signature
Re: [CFT] UNIQUENAME patches
On 13 June 2012 16:21, Matthew Seaman matt...@freebsd.org wrote:
Dear all,
After recent mention in this list that UNIQUENAME is not actually a
unique name for each port and how obviously non-sensical that is, plus
how it causes various problems with OPTIONS processing and how having a
proper UNIQUENAME will facilitate the new sub-package functionality
currently on the drawing board.
So, here are some patches:
http://people.freebsd.org/~matthew/uniquename/uniquenames.diff
There's also some data on the effect these have on OPTIONSFILE and
UNIQUENAME values per port in
http://people.freebsd.org/~matthew/uniquename/before/*
http://people.freebsd.org/~matthew/uniquename/after/*
Summarizing the changes:
* UNIQUENAME is now unique per port, and is primarily derived from
the port directory name.
* Where the port directory name isn't unique (eg. accessibility/orca
vs graphics/orca) there is a new UNIQUEPREFIX variable to
distinguish the affected ports. This is set for all the LANG
specific category ports (arabic, chinese, french, german, hebrew,
hungarian, japanese, korean, polish, portuguese, russian,
ukranian, vietnamese) to the standard 2 character abbreviation for
that LANG. Otherwise it is only set for the specific ports where
there is a directory name collision, usually based on the category
names.
* To avoid accidental non-uniqueness, UNIQUENAME should be treated
as a read-only variable by port maintainers. UNIQUEPREFIX should
only be set where necessary to resolve conflicts. All instances of
ports setting UNIQUENAME have been removed: in the majority of
cases, this turned out to be a no-op as the new UNIQUENAME turned
out to be the same as what most ports were previously overriding
it to.
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Chris
___
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
kde 4.8.4
I've upgraded all kde4 to kde4.8.4 except for kdenetwork. It breaks as shown below but I have no idea where to begin to look to try and fix it. [ 12%] Building CXX object kget/CMakeFiles/kgetcore.dir/core/urlchecker.o [ 12%] Building CXX object kget/CMakeFiles/kgetcore.dir/settings.o [ 12%] Building CXX object kget/CMakeFiles/kgetcore.dir/core/transfertreemodel.o [ 12%] Building CXX object kget/CMakeFiles/kgetcore.dir/core/verifier.o [ 12%] Building CXX object kget/CMakeFiles/kgetcore.dir/transferadaptor.o [ 12%] Building CXX object kget/CMakeFiles/kgetcore.dir/verifieradaptor.o Linking CXX shared library ../lib/libkgetcore.so [ 12%] Built target kgetcore 1 error *** [all] Error code 2 1 error *** [do-build] Error code 1 Stop in /usr/ports/net/kdenetwork4. Any suggestions as to how to fix it would be great. Thanks, ed Have a great weekend. ___ 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: p5-Locale-gettext fails
On Wed, Jun 13, 2012 at 10:59 PM, Torfinn Ingolfsen tin...@gmail.com wrote: What's wrong with devel/p5-Locale-gettext all of a sudden? Please ignore, this was a local problem. Turned out the the SSD was starting to corrupt files. Luckily I got a backup off the drive in time, and the SSSD was fixed by upgrading firmware on it. -- Regards, Torfinn Ingolfsen ___ 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: kde 4.8.4
On 16-6-2012 15:30, Edwin L. Culp W. wrote: I've upgraded all kde4 to kde4.8.4 except for kdenetwork. It breaks as shown below but I have no idea where to begin to look to try and fix it. [ 12%] Building CXX object kget/CMakeFiles/kgetcore.dir/core/urlchecker.o [ 12%] Building CXX object kget/CMakeFiles/kgetcore.dir/settings.o [ 12%] Building CXX object kget/CMakeFiles/kgetcore.dir/core/transfertreemodel.o [ 12%] Building CXX object kget/CMakeFiles/kgetcore.dir/core/verifier.o [ 12%] Building CXX object kget/CMakeFiles/kgetcore.dir/transferadaptor.o [ 12%] Building CXX object kget/CMakeFiles/kgetcore.dir/verifieradaptor.o Linking CXX shared library ../lib/libkgetcore.so [ 12%] Built target kgetcore 1 error *** [all] Error code 2 1 error *** [do-build] Error code 1 Please retry as make -DDISABLE_MAKE_JOBS build. That will show us the real error. -- Mel ___ 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] UNIQUENAME patches
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
signature.asc
Description: OpenPGP digital signature
Re: [CFT] UNIQUENAME patches
On 16 June 2012 15:13, Matthew Seaman matt...@freebsd.org wrote:
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Very thoughtful, OK. You'll also need some sort of cronjob then to
yell at people who duplicate UNIQUENAME then, rather like erwin's
LATEST_LINK script; ports/Tools/scripts/check-latest-link.
Chris
___
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] UNIQUENAME patches
On 16-6-2012 15:18, Chris Rees wrote:
On 13 June 2012 16:21, Matthew Seaman matt...@freebsd.org wrote:
Dear all,
After recent mention in this list that UNIQUENAME is not actually a
unique name for each port and how obviously non-sensical that is, plus
how it causes various problems with OPTIONS processing and how having a
proper UNIQUENAME will facilitate the new sub-package functionality
currently on the drawing board.
So, here are some patches:
http://people.freebsd.org/~matthew/uniquename/uniquenames.diff
There's also some data on the effect these have on OPTIONSFILE and
UNIQUENAME values per port in
http://people.freebsd.org/~matthew/uniquename/before/*
http://people.freebsd.org/~matthew/uniquename/after/*
Summarizing the changes:
* UNIQUENAME is now unique per port, and is primarily derived from
the port directory name.
* Where the port directory name isn't unique (eg. accessibility/orca
vs graphics/orca) there is a new UNIQUEPREFIX variable to
distinguish the affected ports. This is set for all the LANG
specific category ports (arabic, chinese, french, german, hebrew,
hungarian, japanese, korean, polish, portuguese, russian,
ukranian, vietnamese) to the standard 2 character abbreviation for
that LANG. Otherwise it is only set for the specific ports where
there is a directory name collision, usually based on the category
names.
* To avoid accidental non-uniqueness, UNIQUENAME should be treated
as a read-only variable by port maintainers. UNIQUEPREFIX should
only be set where necessary to resolve conflicts. All instances of
ports setting UNIQUENAME have been removed: in the majority of
cases, this turned out to be a no-op as the new UNIQUENAME turned
out to be the same as what most ports were previously overriding
it to.
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
I'm also for getting rid of the badly chosen default. Since origins are
unique within the tree, we can simply use:
UNIQUENAME=${PORTORIGIN:S,/,,}
Then once you get childports (tis the new and improved name for
subpackages) you can tack that on there in the same way.
On 16-6-2012 16:13, Matthew Seaman wrote:
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
This causes exactly the problem you're trying to solve. When ports get
moved to a new location, they are for all intents and purposes new ports.
Using an origin-based UNIQUENAME makes the most sense and does the right
thing for the common case.
The issue here is that pkgng has problems with the MOVED format and
wishes to tack on to UNIQUENAME to solve it's problem. The obvious
solution here is to come up with a better MOVED format. Although, to me
it isn't clear what the problem is. I doubt it's the MOVED file, it's
probably more to do with ports that change their name based on dependency.
If you really want to track a port even if it's changing locations, then
you really should use some kind of GUID and provide a query interface
for the set options -- which we already have.
You could probably generate the GUIDs on port creation with an svn hook.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory.
If you change the default and ensure it is unique by design, then
migrating options for the user isn't that hard:
OLDSCHEME=${PKGNAMEPREFIX}${PORTNAME}
OLDOPTIONSFILE=${PORT_DBDIR}/${OLDSCHEME}/options
.if exists(${OLDOPTIONSFILE})
_CONFIG_SEQ=migrate-config ${CONFIG_SEQ}
.endif
migrate-config:
@${ECHO_CMD} An options file has been found using the old
@${ECHO_CMD} naming scheme. Would you like to migrate these
@${ECHO_CMD} settings?
...etc
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
I doubt UNIQUENAME is used in casual end user to maintainer
conversations. :)
--
Mel
___
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] UNIQUENAME patches
On Sat, Jun 16, 2012 at 03:13:28PM +0100, Matthew Seaman wrote:
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
I'm strongly against adding something related to the category automatically.
Because I'm thinking about binary managerment, adding PKGCATEGORY to uniquename
would mean a package tracking will be lots in case of moving a port from a
category to another. Currently in pkgng a package is identified by its origin
and thus can't survive automatically from a move, because origin changes.
Having a uniquename able to survive from move can help a lot avoiding complex
detection of move and keeping tracking easily the package.
What could be added is a UNIQUENAMESUFFIX to be able to have a finer grain name.
regards,
Bapt
pgp8xVJcBcDZF.pgp
Description: PGP signature
Re: [CFT] UNIQUENAME patches
On 16-6-2012 16:53, Baptiste Daroussin wrote:
On Sat, Jun 16, 2012 at 03:13:28PM +0100, Matthew Seaman wrote:
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
I'm strongly against adding something related to the category automatically.
Because I'm thinking about binary managerment, adding PKGCATEGORY to
uniquename
would mean a package tracking will be lots in case of moving a port from a
category to another. Currently in pkgng a package is identified by its origin
and thus can't survive automatically from a move, because origin changes.
You should solve this using a better index format. I figured out years
ago that the INDEX format used by the ports system is not a good format
for binary upgrades.
http://lists.freebsd.org/pipermail/freebsd-questions/2008-December/187796.html
--
Mel
___
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: kde 4.8.4
Mel Flynn rfl...@acsalaska.net writes: Please retry as make -DDISABLE_MAKE_JOBS build. That will show us the real error. And please have CMAKE_VERBOSE set so we can see the full command line of the call that's causing problems. ___ 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] UNIQUENAME patches
On 16/06/2012 15:26, Chris Rees wrote:
On 16 June 2012 15:13, Matthew Seaman matt...@freebsd.org wrote:
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Very thoughtful, OK. You'll also need some sort of cronjob then to
yell at people who duplicate UNIQUENAME then, rather like erwin's
LATEST_LINK script; ports/Tools/scripts/check-latest-link.
http://people.freebsd.org/~matthew/uniquename/uniquecheck
needs to grow the capability to send e-mails.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
signature.asc
Description: OpenPGP digital signature
Re: [CFT] UNIQUENAME patches
On Sat, Jun 16, 2012 at 05:06:36PM +0200, Mel Flynn wrote:
On 16-6-2012 16:53, Baptiste Daroussin wrote:
On Sat, Jun 16, 2012 at 03:13:28PM +0100, Matthew Seaman wrote:
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
I'm strongly against adding something related to the category automatically.
Because I'm thinking about binary managerment, adding PKGCATEGORY to
uniquename
would mean a package tracking will be lots in case of moving a port from a
category to another. Currently in pkgng a package is identified by its
origin
and thus can't survive automatically from a move, because origin changes.
You should solve this using a better index format. I figured out years
ago that the INDEX format used by the ports system is not a good format
for binary upgrades.
http://lists.freebsd.org/pipermail/freebsd-questions/2008-December/187796.html
--
Mel
Before saying that you should have a look at what pkgng is. pkgng doesn't give a
shit about index. and changing the INDEX won't solve that if you have no way
unique way to identify a package you are doomed, have a look at every single
package management system in the world, all of the sane one with real binary
management system have a unique way to identify packages. We don't !
Bapt
pgpElXyexDmBE.pgp
Description: PGP signature
Re: [CFT] UNIQUENAME patches
On Sat, Jun 16, 2012 at 05:11:25PM +0200, Baptiste Daroussin wrote:
On Sat, Jun 16, 2012 at 05:06:36PM +0200, Mel Flynn wrote:
On 16-6-2012 16:53, Baptiste Daroussin wrote:
On Sat, Jun 16, 2012 at 03:13:28PM +0100, Matthew Seaman wrote:
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
I'm strongly against adding something related to the category
automatically.
Because I'm thinking about binary managerment, adding PKGCATEGORY to
uniquename
would mean a package tracking will be lots in case of moving a port from a
category to another. Currently in pkgng a package is identified by its
origin
and thus can't survive automatically from a move, because origin changes.
You should solve this using a better index format. I figured out years
ago that the INDEX format used by the ports system is not a good format
for binary upgrades.
http://lists.freebsd.org/pipermail/freebsd-questions/2008-December/187796.html
--
Mel
Before saying that you should have a look at what pkgng is. pkgng doesn't
give a
shit about index. and changing the INDEX won't solve that if you have no way
unique way to identify a package you are doomed, have a look at every single
package management system in the world, all of the sane one with real binary
management system have a unique way to identify packages. We don't !
Bapt
Forgot to say that origin is a good way to identify a package until we will have
sub packages (which we really need)
sub package will mean N packages will have the same origin. that way origin will
not become unique anymore.
regards,
Bapt
pgpbvWRtap6m5.pgp
Description: PGP signature
Re: Building gimp-2.8
Ruslan Mahmatkhanov cvs-...@yandex.ru wrote: Heino Tiedemann wrote on 22.05.2012 23:56: ajtiMlum...@gmail.com wrote: On Monday 07 May 2012 06:56:00 Matthieu Volat wrote: Hello everybody, As gimp 2.8 was released a few days ago, I naturaly tried to get it working on my 9.0-RELEASE desktop :) I forked a few ports directories to bump gimp and the dependancies to the needed versions. Everything seems to work quite nicely. I'm sure those modifications cannot be pushed right now in the ports tree, there are quite a few version bump that would impact other ports, but I'd like to share them anyway. I've attached a tarball of my files, here are the list of modified ports: glib20 - 2.30.2 gio-fam-backend - 2.30.2 atk - 2.2.0 gtk - 2.24.10 gdk-pixbuf2 - 2.24.1 pango - 1.29.4 babl - 0.1.10 gegl - 0.2.0 gimp - 2.8.0 I hope it can help people wanting to upgrade to the lastest version of gimp. I like to give a try but I am not familliar with ports (I never dd). Maybe we will be lucky and GIMP 2.8 show in ports soon. Is here any maintainer who can tell - is there a gimp 2.8 at the and of the tunnel? :) When it is there? Heino There is a patch from Koop Mast, that updates gimp to 2.8 (and gegl/babl too). But new gimp also requires more fresh atk and all of this needs testing. I can't recall the link for kwm's patch, and will not put one that I have somewhere, because there is possibility that there is updated version of it. Koop, can you please post that patch link here so the interested people can check it on their own? What about now - 3 weeks later? Is there any timeline for the actual gimp? 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: [CFT] UNIQUENAME patches
On 16/06/2012 15:53, Baptiste Daroussin wrote: What could be added is a UNIQUENAMESUFFIX to be able to have a finer grain name. That's certainly possible, but I was thinking about your plans to create sub-packages. As I understand it, you'll be building and installing each port into a staging area, and then creating a number of different packages from what's in the staging area. So for a port foo, you might create: foo-0.99 --- the foo application and libfoo.so.0 shared library foo-docs-0.99 --- documentation foo-examples-0.99 --- example configurations etc. foo-devlibs-0.99 --- *.h headers, libfoo.a static lib, profiling libs and other things useful for developers. and so forth. So these are distinct packages all from one port with its own UNIQUENAME and hence all using that port's OPTIONS settings, and all built in one block. Having UNIQUENAMESUFFIX for docs, examples, devlibs etc. would imply all of those are entirely separate ports, like the way bacula and bacula-docs are handled at the moment. I can see there will need to be some sort of SUBPACKAGESUFFIXES variable and associated gubbins in the ports makefiles, to do that, plus something like tagging the entries in pkg-plist to identify which sub-package they should belong to. Trying to mix that with UNIQUENAMESUFFIXes would get pretty complicated. Not to mention the question of foo-devel -- is that the devel sub-package of the foo port, or a separate foo-devel port?[*] Cheers, Matthew [*] Hmmm... maybe sub-packages suffixes should use a different separator: foo-0.99, foo--docs-0.99, foo--examples-0.99 foo--devlibs-0.99 (?) -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: [CFT] UNIQUENAME patches
On Sat, Jun 16, 2012 at 04:49:22PM +0100, Matthew Seaman wrote: On 16/06/2012 15:53, Baptiste Daroussin wrote: What could be added is a UNIQUENAMESUFFIX to be able to have a finer grain name. That's certainly possible, but I was thinking about your plans to create sub-packages. As I understand it, you'll be building and installing each port into a staging area, and then creating a number of different packages from what's in the staging area. So for a port foo, you might create: foo-0.99 --- the foo application and libfoo.so.0 shared library foo-docs-0.99 --- documentation foo-examples-0.99 --- example configurations etc. foo-devlibs-0.99 --- *.h headers, libfoo.a static lib, profiling libs and other things useful for developers. and so forth. So these are distinct packages all from one port with its own UNIQUENAME and hence all using that port's OPTIONS settings, and all built in one block. Having UNIQUENAMESUFFIX for docs, examples, devlibs etc. would imply all of those are entirely separate ports, like the way bacula and bacula-docs are handled at the moment. I can see there will need to be some sort of SUBPACKAGESUFFIXES variable and associated gubbins in the ports makefiles, to do that, plus something like tagging the entries in pkg-plist to identify which sub-package they should belong to. Trying to mix that with UNIQUENAMESUFFIXes would get pretty complicated. Not to mention the question of foo-devel -- is that the devel sub-package of the foo port, or a separate foo-devel port?[*] Yes you are right regards, Bapt pgp4SeyYjhbcS.pgp Description: PGP signature
Re: kde 4.8.4
2012/6/16 Raphael Kubo da Costa rak...@freebsd.org Mel Flynn rfl...@acsalaska.net writes: Please retry as make -DDISABLE_MAKE_JOBS build. That will show us the real error. And please have CMAKE_VERBOSE set so we can see the full command line of the call that's causing problems. ___ 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 It broke at : 73%] Building CXX object kopete/protocols/jabber/googletalk/libjingle/talk/examples/call/CMakeFiles/call.dir/console.o^Jcd /usr/ports/net/kdenetwork4/ /usr/local/lib/libmediastreamer.so: undefined reference to `snd_pcm_hw_params@ALSA_0.9' I have attached a file with this begining to the end. Hopefully this will make it easier. Thanks, ed /usr/ports/net/kdenetwork4 # echo ^J[ 73%] Building CXX object kopete/protocols/jabber/googletalk/libjingle/talk/examples/call/CMakeFiles/call.dir/console.o^Jcd /usr/ports/net/kdenetwork4/ /usr/local/lib/libmediastreamer.so: undefined reference to `snd_pcm_hw_params@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_mixer_selem_get_playback_volume_range@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_mixer_first_elem@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_mixer_elem_next@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_mixer_selem_set_capture_volume_all@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_pcm_state@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_pcm_open@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_pcm_start@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_mixer_selem_set_playback_volume_all@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_mixer_attach@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_pcm_sw_params_set_start_threshold@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_card_get_name@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_mixer_selem_get_capture_volume_range@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_mixer_selem_set_playback_switch_all@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_pcm_prepare@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_mixer_selem_get_playback_volume@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_pcm_hw_params_any@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_pcm_sw_params_sizeof@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_pcm_drain@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_mixer_selem_has_capture_volume@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_pcm_avail_update@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_pcm_close@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_pcm_hw_params_set_period_size_near@ALSA_0.9.0rc4' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_mixer_open@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_mixer_selem_register@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_mixer_selem_has_playback_switch@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_pcm_hw_params_set_channels@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_pcm_hw_params_set_access@ALSA_0.9' /usr/local/lib/libmediastreamer.so: undefined reference to `snd_pcm_hw_params_set_rate_near@ALSA_0.9.0rc4' *** [kopete/protocols/jabber/googletalk/libjingle/talk/examples/call/googletalk-call] Error code 1 Stop in /usr/ports/net/kdenetwork4/work/kdenetwork-4.8.4/build. *** [kopete/protocols/jabber/googletalk/libjingle/talk/examples/call/CMakeFiles/call.dir/all] Error code 1 Stop in /usr/ports/net/kdenetwork4/work/kdenetwork-4.8.4/build. *** [all] Error code 1 Stop in /usr/ports/net/kdenetwork4/work/kdenetwork-4.8.4/build. *** [do-build] Error code 1 Stop in /usr/ports/net/kdenetwork4. *** [build] Error code 1 Stop in /usr/ports/net/kdenetwork4. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: How to uninstall pkgng
On Sat, 09 Jun 2012 19:56:56 +0200, Julien Laffaye wrote: On 6/9/2012 7:46 PM, Marcin Wisnicki wrote: I've made a mistake of installing pkgng on 9.0-amd64 but since there is no up-to-date repository I want to remove it. Have you looked at http://pkgbeta.freebsd.org/freebsd-9-amd64/latest/ ? Yes, it was 3 weeks behind -i386 at the 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: How to uninstall pkgng
On Sat, Jun 16, 2012 at 04:26:59PM +, Marcin Wisnicki wrote: On Sat, 09 Jun 2012 19:56:56 +0200, Julien Laffaye wrote: On 6/9/2012 7:46 PM, Marcin Wisnicki wrote: I've made a mistake of installing pkgng on 9.0-amd64 but since there is no up-to-date repository I want to remove it. Have you looked at http://pkgbeta.freebsd.org/freebsd-9-amd64/latest/ ? Yes, it was 3 weeks behind -i386 at the 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 It is now up to date pgpodr7MVVvyg.pgp Description: PGP signature
Re: kde 4.8.4
Edwin L. Culp W. edwinlc...@gmail.com writes: It broke at : 73%] Building CXX object kopete/protocols/jabber/googletalk/libjingle/talk/examples/call/CMakeFiles/call.dir/console.o^Jcd /usr/ports/net/kdenetwork4/ /usr/local/lib/libmediastreamer.so: undefined reference to `snd_pcm_hw_params@ALSA_0.9' I have attached a file with this begining to the end. Hopefully this will make it easier. Did you have the alsa ports installed when you built mediastreamer and remove them later or something like that? ___ 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] UNIQUENAME patches
On 2012-06-16 17:49, Matthew Seaman wrote: On 16/06/2012 15:53, Baptiste Daroussin wrote: What could be added is a UNIQUENAMESUFFIX to be able to have a finer grain name. That's certainly possible, but I was thinking about your plans to create sub-packages. As I understand it, you'll be building and installing each port into a staging area, and then creating a number of different packages from what's in the staging area. So for a port foo, you might create: foo-0.99 --- the foo application and libfoo.so.0 shared library foo-docs-0.99 --- documentation foo-examples-0.99 --- example configurations etc. foo-devlibs-0.99 --- *.h headers, libfoo.a static lib, profiling libs and other things useful for developers. and so forth. So these are distinct packages all from one port with its own UNIQUENAME and hence all using that port's OPTIONS settings, and all built in one block. Having UNIQUENAMESUFFIX for docs, examples, devlibs etc. would imply all of those are entirely separate ports, like the way bacula and bacula-docs are handled at the moment. This looks like most RPM packages are build but with one major difference With one RPM spec file you can build foo, foo-docs, foo-devlibs and foo-examples in one build and get 4 rpm's in one run. With the ports infrastructure we have to run several builds one for foo, one for foo-devlibs and maybe one for foo-docs if docs are generated. Here we can take bacula, pgsql or mysql as example. To build the server and the client the build is done twice and only different files are taken to crate the package. Unless the ports infrastructure can build several packages from one port in one run this looks for me very impractical and time consuming. Also DEPENDENCY handling can become a real mess if a port needs foo, foo-devlibs , bar, bar-devlibs ... to build. Even this writeup looks critical I think I like the idea to split the packages if pkg has also the ability to search for packages like 'yum search' or apt .. I always smiled if I read Linux $fillInDistro has x thousands packages and if you look seriously divide the amount by 3 or 4 to get a real number. I suspect FreeBSD will be hit easily 50.000 packages with this split. How much additional time will take to do a full portstree build ?? I can see there will need to be some sort of SUBPACKAGESUFFIXES variable and associated gubbins in the ports makefiles, to do that, plus something like tagging the entries in pkg-plist to identify which sub-package they should belong to. Trying to mix that with UNIQUENAMESUFFIXes would get pretty complicated. Not to mention the question of foo-devel -- is that the devel sub-package of the foo port, or a separate foo-devel port?[*] [*] Hmmm... maybe sub-packages suffixes should use a different separator: foo-0.99, foo--docs-0.99, foo--examples-0.99 foo--devlibs-0.99 (?) Looks silly but you have more then the '-' (_ + %) for example foo+docs, foo__docs, foo%docs -- Regards, olli ___ 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] UNIQUENAME patches
On 16/06/2012 20:11, Olli Hauer wrote: With one RPM spec file you can build foo, foo-docs, foo-devlibs and foo-examples in one build and get 4 rpm's in one run. With the ports infrastructure we have to run several builds one for foo, one for foo-devlibs and maybe one for foo-docs if docs are generated. Exactly -- that's precisely the functionality that sub-packages is going to introduce for the ports. You do one build stage, and can then split up the results into several different packages. One port, several pkgs. This will require the use of a staging directory, so you can package up a port without having to have it installed. Staging is another new feature currently on the drawing board. Also DEPENDENCY handling can become a real mess if a port needs foo, foo-devlibs , bar, bar-devlibs ... to build. Well, maybe. For an end-user system where you install from pkgs (in this case, meaning pkgng -- that's the driver for most of these new features ) you only really need the base 'foo-0.99' package: dependencies will be pretty much equivalent to what there is now. Optionall you'll probably want foo--docs and foo--examples too, but you don't have to have them if installing a really stripped down system. There will probably be some sort of global setting to say automatically install docs and/or examples when you install the primary port. When you're doing pkg building, then yes, you'ld need to install a bunch more pkgs -- they'd be BUILD_DEPENDS rather than RUN_DEPENDS -- but the ports infrastructure should take care of that. Using a package builder like poudriere to maintain your own pkg repo should become standard procedure for supporting any reasonably sized installation, and that will gloss over all the boring detail of that for you. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Emacs?
Heino Tiedemann writes: Hi, emacs 24 final is out There isn't an emacs 24 final in editors/emacs neither in editors/emacs-devel is there someone working on that? Hi Heino, I'm the maintainer of editos/emacs*, and I'm working on it. It'll take a bit of time, because it'll require an -exp run (for changes to bsd.emacs.mk). HTH -- Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0 freebsd.org!ashish | http://people.freebsd.org/~ashish/ Sent from my Emacs pgphwTdjg9L1V.pgp Description: PGP signature
Re: [CFT] UNIQUENAME patches
On 2012-06-16 22:36, Matthew Seaman wrote: On 16/06/2012 20:11, Olli Hauer wrote: With one RPM spec file you can build foo, foo-docs, foo-devlibs and foo-examples in one build and get 4 rpm's in one run. With the ports infrastructure we have to run several builds one for foo, one for foo-devlibs and maybe one for foo-docs if docs are generated. Exactly -- that's precisely the functionality that sub-packages is going to introduce for the ports. You do one build stage, and can then split up the results into several different packages. One port, several pkgs. sounds good This will require the use of a staging directory, so you can package up a port without having to have it installed. Staging is another new feature currently on the drawing board. Also DEPENDENCY handling can become a real mess if a port needs foo, foo-devlibs , bar, bar-devlibs ... to build. Well, maybe. For an end-user system where you install from pkgs (in this case, meaning pkgng -- that's the driver for most of these new features ) you only really need the base 'foo-0.99' package: dependencies will be pretty much equivalent to what there is now. Optionall you'll probably want foo--docs and foo--examples too, but you don't have to have them if installing a really stripped down system. There will probably be some sort of global setting to say automatically install docs and/or examples when you install the primary port. When you're doing pkg building, then yes, you'ld need to install a bunch more pkgs -- they'd be BUILD_DEPENDS rather than RUN_DEPENDS -- but the ports infrastructure should take care of that. Using a package builder like poudriere to maintain your own pkg repo should become standard procedure for supporting any reasonably sized installation, and that will gloss over all the boring detail of that for you. also sounds good to me, at the moment I stopped testing pkgng since I use exclusive tinderbox with several builds for prod machines and haven't had the time to look deeper into the ./tb tbcleanup bug (tb head) which wiped twice a view builds from two different build machines. http://www.marcuscom.com/pipermail/tinderbox-list/2012-May/002601.html -- Regards, olli ___ 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: Skype 4.0
On Fri, 15 Jun 2012 23:02:43 -0700 (PDT) Waitman Gobble uzi...@da3m0n8t3r.com wrote: dude like since MS bought it they haven't even released any non-win32 version. i agree, a different alternative to skype is better, and get your contacts to join up with that. If you don't count Mac, Android, and some other .. -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B ___ 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: Skype 4.0
On Fri, 15 Jun 2012 17:11:03 -0400 Rich Neese r.ne...@gmail.com wrote: On 6/15/2012 5:08 PM, Robert Simmons wrote: On Fri, Jun 15, 2012 at 1:08 PM, Jerry je...@seibercom.net wrote: Skype 4.0 for Linux is now available. Is there any possibility of getting it ported to FreeBSD? The latest version in ports is only 2.x. I don't have time to do it right at the moment, but since this is pre-compiled binary software, updating the port yourself and sending the patches in with a PR would not be a complex task. I'm confident that you could do it. Start here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/quick-porting.html The URL for downloading the bugger is here: http://download.skype.com/linux/skype_static-4.0.0.7.tar.bz2 Good luck, and thanks in advance! It also needs to run, which it doesn't for lack of linux emulation things and some linux- ports. I just wish skype would get off their buts and make a bsd version. time to break code and make a opensource version 0 chances. As a market we're not significant at all for them. Even Linux isn't, not really. -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B ___ 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
Nginx SPDY support patch
Hi This patch adds an option to build nginx-devel with the recently announced spdy patch, it alse cleans up some errors flagged by portlint which allows port test to build this port http://pastebin.com/hfhjhukQ Sevan / Venture37 ___ 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
