Re: Wicd
On Sun, 2011-11-06 at 12:10 -0600, user 5813 wrote: Has anyone heard of someone attempting to port Wicd to FreeBSD? I have googled this over and over and found nothing. If not, how would I begin to learn about porting it? I know it is in python and would probably only require some tweaking to include ifconfig instead of iwconfig. I am very new to BSD and programming and need to know where to start. I have read the handbook on porting but there are still some pieces missing for me. I think where I am stuck at is the actual tweaking of the program to make it run under BSD. Should I just make a Makefile and see if it builds before anything else? There is no universal magic for porting a program to FreeBSD that could be applied to any or all of them. You need to get the program working [properly] first, making a port from your result comes as a final step after that. There is no way of universally helping you porting some program until there are any questions, or any actual issues, which you didn't provide. Porter's Handbook almost exclusively deals with creating (and maintaining) the final port itself in the sense of the FreeBSD Ports infrastructure, this is not yet (very) interesting to you as you don't seem to have any actual product you're trying to make a port from. So if you need help in making some program work properly under FreeBSD, first thing would be to describe what is wrong currently, what results are you trying to achieve, and ask around for possible solutions for this or that issue. When you have all the issues worked out and the prototype seems to be working about right, it's time to start building the final and true port of it, and possibly offer it to wider audience for some testing, before submitting the port as a final product. At this point, it's not that important trying to figure out the final part, as you have still kind of a long way ahead of you getting the program actually working. So, my suggestion would be starting there. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: dconf gconf wtfconf ?
On Thu, 2011-11-03 at 00:21 -0400, Jason Hellenthal wrote: Can anyone explain the difference or need for both of these ? ports/devel/gconf -( Should'nt this be the only one needed ? ) ports/devel/dconf I just noticed dconf installed on my system. Both of these have the same WWW: of: http://www.gnome.org/projects/gconf/ While dconf is a successor of gconf, it's not a drop-in replacement. Currently you need both. As a rule of thumb, Gnome2-era applications will be using gconf (some might keep using it for years to come,qq so gconf isn't going away), while most recent Gnome3-era applications already migrated, or are in the process of migration to dconf (note that even the base Gnome3 didn't yet fully moved to dconf as of Gnome 3.2) m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: KDE3 de facto EOL, Project Trinity?
On Tue, 2011-10-11 at 16:32 +0400, Konstantin Tokarev wrote: 09.10.2011, 22:30, Jakub Lach: Speaking of lightness, XFCE is memory hungry these days and Linux centric, and Fluxbox is not that light after all. Are you saying that Fluxbox is heavier than KDE3?? Especially when Fluxbox is a window manager and KDE is an desktop environment. Comparing those two on the same scale is like comparing FreeBSD to an ssh client. m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Testing Wacom usb tablet with webcamd svn (and mypaint)
On Tue, 2011-10-11 at 20:21 +0200, Juergen Lock wrote: No. webcamd has become kind of a misnomer, it's in fact just a `wrapper' for several kinds of Linux usb kernel drivers to run them in FreeBSD userland. (We have now at least webcams, dvb tuners, IR transceivers, and usb tablets. :) Oh god, thank you for mentioning this. I've been personally keeping webcamd out of my installations as we don't need no stinkin webcams here, but this is something completely different based on what you say (especially the Wacom support). Was there any push to rename webcamd to something more meaningful yet? m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Testing Wacom usb tablet with webcamd svn (and mypaint)
On Tue, 2011-10-11 at 21:39 +0200, Hans Petter Selasky wrote: On Tuesday 11 October 2011 21:31:02 Juergen Lock wrote: On Tue, Oct 11, 2011 at 08:35:49PM +0200, Michal Varga wrote: On Tue, 2011-10-11 at 20:21 +0200, Juergen Lock wrote: No. webcamd has become kind of a misnomer, it's in fact just a `wrapper' for several kinds of Linux usb kernel drivers to run them in FreeBSD userland. (We have now at least webcams, dvb tuners, IR transceivers, and usb tablets. :) Oh god, thank you for mentioning this. I've been personally keeping webcamd out of my installations as we don't need no stinkin webcams here, but this is something completely different based on what you say (especially the Wacom support). Was there any push to rename webcamd to something more meaningful yet? I'm not aware of anything like that... In my talk at EuroBSDcon I said that webcamd might be renamed in the future. Does anyone have any good suggestions? --HPS Well if you insist on the d ending, something along, say, usblinuxd? Or possibly kmodlinux[d], if USB isn't going to be the absolute target forever... m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: Remove dependency on xz - How?
On Fri, 2011-09-16 at 02:45 -0500, Lars Eighner wrote: archivers/xz is mark IGNORE because xz is now in the base system (8.2) Numerous other ports won't build because they believe they depend on xz (or on a port that depends on xz) I'd like to remove the dependencies on xz from the pkgs database. pkgdb -s /xz-5.0.0// won't work as the slash notation might suggest it would because -s does not accept a 'empty argument' I am afraid to remove the xz package because it seems to me it would delete the base system xz -- and I don't want to make world if I can avoid it. Try: $ ls -l /usr/bin/xz $ ls -l /usr/local/bin/xz $ pkg_which /usr/local/bin/xz In short: It won't. Ports generally do not install into base hier(7). Also, even if case such situation happened, you'd be much quicker with: # cd /usr/src/usr.bin/xz # make clean # make # make install [ # make clean ] Is there some sensible way to do this? Force deinstall xz package, run pkgdb -Fuf, confirm deleting the unneeded dependency (if asked), and you're done. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: cvs commit: ports/x11/nvidia-driver Makefile distinfo
On Wed, 2011-09-14 at 07:38 -0400, Jerry wrote: On Wed, 14 Sep 2011 13:01:50 +0200 Alex Dupre articulated: Dmitry Marakasov ha scritto: * Alexey Dokuchaev (da...@freebsd.org) wrote: Log: - Update NVidia drivers to their corresponding latest versions - Apply a workaround to fix the build on recent -CURRENT after fget(9) KPI was changed in r224778 (affects the driver since version 195.22) Just for everyone's information, I've had system freezes with 280.13, 8.2-RELEASE i386, GeForce 9800 GT. I can confirm the freeze with 8.2 amd64 and a GeForce GTS 450. I had to downgrade to 270.41.19. I just checked on one of my machines, and it is working correctly. dmesg | grep -i geforce nvidia0: GeForce GT 220 on vgapci0 This is a FreeBSD-8.2 amd64 machine and the card is not exactly start of the art either. I'm using 280.13 since the hour it came out (atm on GeForce GT 240 8.2-STABLE i386) for 2D and 3D graphics work, VDPAU video acceleration, 3D gaming, desktop effects, for about 20 hours a day on average. I have yet to see a single freeze or any other issue. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: Thank you (for making the ports less boring).
] and thus my current work on constantly fixing *my* FreeBSDs is cut down by 99%, I'm all hands in for some good old fashioned volunteering. You know, except that I won't have a slightest idea on how much FreeBSD ports are broken on the large scale (yes, my FreeBSD servers with a limited scope of ports still run perfectly fine over the decade, thank you), but that's but a minor issue that nobody around seems to be bothered with, so I guess I will be fine too in that case. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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
Thank you (for making the ports less boring).
days, other than rolling back ports and catching up/fixing breakages? For myself, I surely can't even imagine. So again, thank you for taking your part in ensuring that my days with FreeBSD (the remaining few, so to say) won't become too boring. It's much appreciated, really. m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ports system quality
On Thu, 2011-09-01 at 04:23 -0500, Mark Linimon wrote: On Mon, Aug 29, 2011 at 07:34:56AM +0200, Michal Varga wrote: - While nobody probably cares much about that guy and his missing browser images, what would you tell to the GIMP guy? That he should have waited longer before upgrading the (for him, 30 levels deep) Foo dependency? With furious client breathing down his neck and everything? Either we want to have ports as a big repository of colorful stuff that even builds, or we want to have some actual products that people can use after they build them. And that needs an additional level of quality control that FreeBSD currently, and horribly, lacks (patches welcome, I know). In that case, you should not be updating that rapidly. I've covered that aspect earlier in the discussion. There is no option to 'upgrade less rapidly', as at any single point in time, there is *always* something that just hit the tree moments before. This would require all ports users always perfectly know every single port in their systems and have detailed knowledge about what exactly every single dependency does, affects, and when it's safe to upgrade this or that, and how soon to do it after a particular (and every single) commit. And letting other people get burned while simply waiting it out doesn't a quality control process make. Just stating the obvious. [And to cut it right here - no, answer to that is not Ok, so everyone should be a tester then. This never worked anywhere outside of dreams and wishes. And no other sane project does, nor tries to go this way.] IMHO you should look at installing PC-BSD, who has a release process where they go through the apps based on a stable state of the ports tree, based on paid employees. Telling people to go using different operating systems when they point out some shortcomings in FreeBSD was already pretty old some decade ago. While I'm not the kind of person to get in any way offended by it, I can easily imagine why so many get bittered by such 'suggestions' and eventually just leave for good. If I was looking for another OS, I wouldn't be wasting all this time pointing out what's broken on FreeBSD (or more specifically, in FreeBSD ports), I would be spending that time migrating, as I would have my options long time researched by then (which I have, actually, as significant part of my work depends on fully working desktop systems and FreeBSD no longer cuts it in that domain for some time). - That particular maintainer of Foo graphics library should be forced, by threats of violence [...] And what happens if he doesn't respond to the threat? We fire him? Look: you can't fire volunteers. Only employees. Yes, and you now single-handedly discovered what's the major point of failure in the current system (and I don't mean that as a sarcasm, nor making fun of anything). While I was making a hyperbole with all the violence and stuff, it still boils down to this. Nobody is really steering this ship anymore and it just happily rams icebergs along the way, with volunteers occasionally throwing buckets of water (and sometimes pieces of furniture) overboard to somehow keep it afloat for a while longer. The current mechanisms for dealing with ports (and their maintainers) were put in place ages ago in different times and with, frankly, somewhat different people around [citation needed]. Over the course of time, amount of ports grew by magnitudes, dependencies, especially for desktop environments grew by magnitudes, and maintainers are no longer the special dedicated bunch of highly motivated people that know every single port and their whole ecosystems inside-out. This is no longer even possible, among other issues (and there are few). But the system in place still pretends things work this way. They don't. Ports are failing, horribly. And it's not the concept that is wrong, it's the execution. Or more like, lack of any proper. But I'm all fine with pretending that nothing really happens and that few more automated -exp runs will save all and forever. Another five years from now, when FreeBSD definitely sinks into the realm of 'irrelevant' and when the finger pointing finally (and way too late) starts, I'll just bring some popcorn and quietly watch the show, just so that I don't offend someone again with my unsubstantiated whining. And let's say that I, as portmgr, tried to impose some kind of rule about what's going to happen to you if you don't do things my way. The upshot? The volunteers will just leave. (They get mad when portmgr tries to bring some sanity to certain chaos-filled areas, as it is.) Yes, and I remember some of 'those' situations. As we - the people who 'don't actually do the work' but sometimes actually use this system - for this or that reason even somehow keep track on what's happening around, as it's affecting both our short- and long- time FreeBSD decisions too. But you're just not doing enough. Doug too doesn't
Re: libproxy and libnotify the story continues :D
On Wed, 2011-08-31 at 09:13 +, Johan Hendriks wrote:
Hello all, i also ran into the libproxy upgrade problems.
So i tried al the stuff i found on the mailling list so far.
I tried the solution from j.kim
find /usr/local/lib -name *.la | \
xargs grep -l /usr/local/lib/libproxy.la | \
xargs -L 1 pkg_info -W | \
awk '{ print $6 }' | \
sort | \
uniq | \
xargs portupgrade -f
But this ends like the following.
/usr/include/machine/endian.h:130: syntax error, unexpected ';' in ' return
(__extension__ ({ register __uint32_t __X = (_x); __asm (bswap %0 : +r
(__X)); __X; }));' at ';'
/libexec/ld-elf.so.1: Shared object libproxy.so.0 not found, required by
libchamplain-0.8.so.1
Command
'['/usr/ports/graphics/libchamplain/work/libchamplain-0.8.1/champlain-gtk/tmp-introspectpyOYLR/GtkChamplain-0.8',
'--introspect-dump=/usr/ports/graphics/libchamplain/work/libchamplain-0.8.1/champlain-gtk/tmp-introspectpyOYLR/types.txt,/usr/ports/graphics/libchamplain/work/libchamplain-0.8.1/champlain-gtk/tmp-introspectpyOYLR/dump.xml']'
returned non-zero exit status 1
gmake[3]: *** [GtkChamplain-0.8.gir] Error 1
gmake[3]: Leaving directory
`/usr/ports/graphics/libchamplain/work/libchamplain-0.8.1/champlain-gtk'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory
`/usr/ports/graphics/libchamplain/work/libchamplain-0.8.1/champlain-gtk'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/usr/ports/graphics/libchamplain/work/libchamplain-0.8.1'
gmake: *** [all] Error 2
*** Error code 1
Stop in /usr/ports/graphics/libchamplain.
I reinstalled libproxy, i reinstalled libgweather and so on, also the poor
mans portmaster solution from doug.
But i can not get past this.
Also did a recompile off all the evolution stuff,
Then tried portmaster lib* in the hope there was a library not installed ok,
but that ends with the same error as above.
I am struggling for a day or 4 now with this.
Could someone please help me :D
This is another iteration of the same old issue:
http://www.mail-archive.com/freebsd-ports@freebsd.org/msg34214.html
m.
--
Michal Varga,
Stonehenge (Gmail account)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ports system quality
On Sun, 2011-08-28 at 23:30 -0700, Doug Barton wrote: Testing only for Does it still build? won't help much anymore if the new version silently broke one of the APIs and while Apache still runs with it fine Believe it or not, I understand that. :) The problem is that extensive run-time testing is not within the realm of possibility without an army of volunteers. Do you want to organize that effort? That would be the very opposite of the concept I just described. While extensive volunteer testing, if considered standalone, is surely not a bad idea (just that for some reason it never happens anywhere), it lies in a completely different scope than port maintainers *not* randomly upgrading dependencies just on their own without regard to other ports they will affect (and in many cases break, be it on build level, or run-time level). I just double checked if I possibly forgot to send the other half of my email, but nope, it's all right there. Now where I'm trying to get by this: Either we want to have ports as a big repository of colorful stuff that even builds, or we want to have some actual products that people can use after they build them. And that needs an additional level of quality control that FreeBSD currently, and horribly, lacks (patches welcome, I know). That sounds like PC-BSD to me. (Seriously, give it a try) Now that's like saying I might want to try *Linux and OS X too (I occasionally use both, just not as my primary desktop, which is FreeBSD). Speaking about PC-BSD, I'm not exactly fan of KDE and also, I find the concept of PBI packages highly offending. Then again, I can't see how would PC-BSD help in this case as it's the exact opposite of what I described. The fact that PC-BSD just tracks ports and builds self-contained packages from them doesn't automagically make them better product, it's still the same ports, but now just horribly packaged too. m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ports system quality
On Mon, 2011-08-29 at 00:17 -0700, Doug Barton wrote: are unlikely to ever get to that point. I would also point out that from a project management standpoint developers rarely make good QA people. To do this right you really would want separate teams. As I said, that's not something that's in my power to change. In any case, it just leads (and always will lead) only to this outcome: Those are good alternatives as well. I use FreeBSD as my desktop, but it's painful, and I wouldn't do it at all if I didn't need to. Other OSes/projects, for some reason, are able to manage their maintainer base to much better results, and it shows. It can either be done here too, or the situation can be ignored for another five, ten years, until FreeBSD fades into obscurity, eventually getting known only as 'that OS where nothing works'. It's an issue that won't go away on its own. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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 handle upgrade of libnotify when cups-client-1.4.8 is marked as broken
On Sun, 2011-08-28 at 17:14 -0400, Sahil Tandon wrote: Replies like these already made me discard like 20 of my own emails in the past, mid-write, exactly because of this expected outcome - accusations of trolling, because, why not, that's really what it's all about, right. Have you followed the rest of the thread, where I (and others) have debated the actual _issue_, rather than engaging in ad hominem attacks towards the parties involved? Disappointment with the ports tree is completely understandable and frustration in this case is warranted, but using inflammatory hyperbole and attacking volunteers is silly. So please, do not conflate being called a troll (when you're actually being one) vs. being labelled one for highlighting a problem. Yes, I have read the thread and that's why I didn't feel need to add anything directly related to _the issue_ - as everything needed was already said, and solved, by that time. I'm not sure why exactly are you accusing me of ad hominem or any other attacks, as I don't remember making any of those. Pointing out that I can easily see why Jerry chose that specific tone of his emails doesn't really make an attack in my book, sorry. Then, I don't think he was really attacking you too, but I'm accustomed to the style of sarcasm he opted for, which might possibly be some cultural thing. It sometimes happens. So to say for myself - I do not know Jerry, but I definitely share his sentiments and even find his tone quite funnily (is that a word?) appropriate, as the ports quality, over the last year, went totally, horribly, down the drain. I'm sorry you feel that way, I hope the quality can improve from what you find to be an unacceptably low level. Now I just hope you're being sarcastic too. And I know that every time I'd start writing a mail about it, my tone would be exactly the same as Jerry chose. With the expected result of Zomg stop trolling, or for a change, the ever popular megahit Patches welcome (yes, like that will help anyone now), without even bothering to read what I'm really trying to complain about. That is unfortunate; can you please share an example of this happening to you in the past on this list? Just so we can put it in context. I don't feel like pointing fingers and that was not my intention in the first place. Also, I've been here for way too long for that. What I was trying to point out that every time someone accuses someone else of trolling just because the guy was genuinely frustrated or angry (and actually, quite right to be), god has to kill a bag of kittens somewhere. Not every person that doesn't write in pink letters is necessarilly a troll, and not every person making a sarcastic comment about a pretty frustrating situation is there to make a personal attack (on you, or anyone else). Did you ever experience the situation down over the supermarket, when someone just takes one's parking spot, on which he exclaims Damn, have you seen that? I'd kill that guy! I hope you understand that he really isn't making any life threats (heck, even if he was, like that means anything). I'd suggest, if I may, rereading Jerry's messages with a glass of wine some time, and when you get to those very offending words, like, criminal, thinking of them more in the context they were written in, instead of just the words alone. It definitely seems to help me, as for some reason I don't find them offending, while on the other hand, being bitten by the same situation, I can appreciate the sarcasm. I don't really think so. I'd simply consider him angry, as for myself, I know how many such emails I personally didn't have nerves to send, and would really, really love to. But somehow I feel, Jerry's is simply a start and there is much more of this to see in the coming future... Your anger is understandable, but attacking people on this list is not. For me, the GNUTLS situation was already more like oh for christ, not again. It would hardly make me genuinely angry these days, with all the breakage happening in ports every other moment. And just being discontent doesn't yet an attack make, no matter how much you see it there. Jerry, while obviously sarcastic, wasn't any vulgar as far as I noticed, and even specifically pointed out in few places that he is not blaming (if I was you, I'd read that as attacking, but that might be just me again) you, specifically. And if you think that now even some random me is just again *attacking* you, because I somehow sympathize with Jerry's position.. Well, I don't know then, but maybe just - harden the LOVE up? (A little bit, maybe.) m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ports system trolling
On Sun, 2011-08-28 at 14:43 -0700, Doug Barton wrote: On 8/28/2011 1:54 PM, Michal Varga wrote: On Sun, 2011-08-28 at 15:30 -0400, Sahil Tandon wrote: [...] Criminal? Indifference? This sort of troll-ish hyperbole is decidedly unhelpful. FWIW, I agree with Sahil that this post of Jerry's was over the top, as several of his have been of late. To use the word criminal in this context is sufficient all on its own. To accuse people who spend an enormous amount of their own free time trying to make this thing work of being indifferent is just plain rude. While I'm the last one to be trying to belittle the effort put by some people into ports (or FreeBSD in general), lately, this particular mantra is starting to get a little overused. I know that it almost borders with criminal (I see what I did there) even trying to suggest that, but seriously - just because someone did a lot this or other day (week, month, or year) for FreeBSD, doesn't make them *untouchable* to critique for the rest of their lives. This is very wrong approach and such way of thinking only leads to a pretty rotten (and pretty elitist) community. Note that I mean it generally, without pointing to any current case at all. It's just... Recently it's being invoked so much that it's on the verge of losing any meaning. Jerry (ok, I'm probably starting to sound like his mother, writing third email about him and all that, but it'd be hard to get to some point without pointing to him directly) clearly stated what was his concern - that there should have been a note put in UPDATING the moment the issue was discovered (I would personally mention *testing* somewhere in there, but that's me), and that the chosen approach - waiting for a maintainer approval to give his permission for a fix when you already have there a situation with mailing list filling up with more and more reports about breaks (meaning, people out there actually get bitten by it right at this very moment, losing them time, losing them money, losing them hair, choose what applies) - is pathetic. Now. Would I personally chose the same words? Definitely not, it's far from being polite and I could easily imagine the shitstorm following it (now just see the shitstorm following me using the word shitstorm). But it's not about the one single word from the whole thread, we are not elementary school children. It's about the situation behind it, and that's the one that really needs addressing, not a bunch of heated words. In such situation, I (personally, again) wouldn't consider this even warranting a quiet off-list warning, it's not like this guy is cross spamming threads and randomly attacking people out there just for fun. Late edit: I was only speaking about the situation happening up until starting this particular reply, now I see things got a little bit more heated in meantime (most of which I didn't read, yet), but that's already out of scope of this. Just to make things clear. On some of my desktop setups, I keep about 900-1000 installed ports (and there are some ~200-300 for servers in general). There already seems not to be a single week, even once, without some MAJOR breakage that always takes hours (sometimes days) to track down and fix by my own ... FWIW, my experience has not been even close to yours, although I do find broken things occasionally. Well, as far as I remember, you weren't using FreeBSD as a desktop OS (or at least weren't much), so this probably contributes to your (better) experience with recent ports. Of course it's just something out of the back of my head, I may be mistaken, but I think I remember you stating it some time, someplace. Anyway - with some 1000 ports on a full feature desktop system (that's like 1/20th of all we have in total, right), be it Gnome or KDE (god help with both), the breakages are massive, and almost constant. On the other hand, this practically doesn't happen on any major Linux distribution (and no, I'm not that guy arguing we should move ports to debian binary packages, there's no need to worry); this wasn't happening in 4.x days too, this wasn't happening in 5.x days and everyone knows what a loving miracle FreeBSD 5 was, this wasn't happening in (early) 6.x days (much), but especially from 7 onwards, and the last year, having a 1000-ports desktop system is just a plain nightmare. There is constantly *something* broken. And not like it's just one thing at a time. Do I have stats for it? No, obviously. If I was making paper notes of that, I'd have eradicated few rainforests by now (errr, so no, I don't have stats for it, but I have my daily experiences maintaining both server and desktop BSDs without a break since 2000, so that leaves some memory here and there). [Rest moved to a standalone email, as it's somewhat long and stuff.] m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http
Re: Ports system quality
application, right? So during his testing, nothing wrong showed up with the new version, as with the limited (non-GTK) scope that he was ever using (and testing) his port for, everything was fine. On the other hand, for desktop users, the new port broke practically everything. Yay. So how would one prevent situations like these without *forcing* volunteers to do job out of the scope they volunteered for? What is the solution for that? Requiring them to test for something they don't even use, or even know? What's the better option then? Having the guy drop maintainership if he is not interested in fully maintaining it as a dependency? Or advertising a working Gnome (KDE, XFCE, whatever) Desktop on FreeBSD, and having down there someone maintaining a low level dependency that can completely break the *desktop OS* every single update, while obviously he is not even testing for it? This is just one of those situations that won't get magically solved by just another ports tree. Obviously, one additional testing tree will catch some of the breakages (depending on number of people willing to deal with unstable ports, and in my humble expectations, that would be like: - almost nobody for server configurations (because why) - almost nobody for desktop configurations, because that would mean desktop that's not even starting 90% of the time, so why even bother ), but being the visionary I am, I think it won't change as much as it now shows on a paper. There already are testing repos for various ports (Gnome, Xorg, VirtualBox, etc.), and barely anyone uses them. What is needed more are new, much stricter maintainership and committing policies than there are in effect now, and seriously - who would dare to even suggest such thing and still live through the mass burning and exodus following it? The other thing that will help between now and then is to manage your change windows a little more conservatively. Except for security-related updates there is almost always zero reason to upgrade to new versions of things immediately after they hit the ports tree. With all due respect to those involved, one of the reasons the ruby thing was such a mess was that users jumped in and started upgrading stuff without knowing what they were doing, or why. Personally as soon as the notice about the upcoming change went out I put the knob in make.conf to keep my systems at 1.8 to make sure I wasn't affected. I'd have to strongly disagree with this point of view. Thing to keep in mind is, that at any point in time, there is always *something* that had just hit the tree only moments ago. What if I had those 30 ports to upgrade (or make it 300 if one upgrades once over a month), all of them being cross/dependencies along the path requiring some of each other, and now I have to cherry pick them and blacklist/exclude some based on their arrival time... That's crazy. Many people haven't even heard about half of those dependencies down the tree (and why should they), and how many of them even don't know that Ruby is a programming language (why should they, it's crap anyway) and that 1.9 is a major upgrade. Why would someone upgrading a web browser, music player (or more specifically, *bringing all his applications up to date*) know about some Ruby and what it is and that 1.8 vs 1.9 can also be a major deal-breaker, when for him, it's just some random dependency 30 levels below? Thinking about upgrading ports in this way would require every single port user to become a maintainer of... everything. What you propose is the opposite of cooldown period - you'd require every ports user keeping track on every single port installed and know 'how important' in the overall scheme it is and when it's safe to update it and when you have to schedule a week-long alarm to let it cool down a bit until it's (probably) safe to use it (as some other people got probably burned and hopefully reported it). This is really a bad idea. When ports hit the tree, they should either be stable and ready to use, or not be there at all. m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ports system trolling
On Sun, 2011-08-28 at 20:25 -0700, Doug Barton wrote: Well, as far as I remember, you weren't using FreeBSD as a desktop OS (or at least weren't much), This is really my day for lolz. :) I have been using FreeBSD as my primary desktop OS for about 13 or 14 years, and have been using -current for most of that time. I also advocate strongly for people to do that, especially developers (and especially especially committers). I see, my bad then. Might be that you were just stating that you're not using Gnome, or KDE, or something along the line and it left a wrong fingerprint in my memory. That's why I said that I'm not really sure. Still, if that's the case, I wonder how your ports experience in that regard could be so good. And substituting a full desktop environment for like xorg+twm+vi doesn't count as a desktop in my book :) (Ok, just trolling. But who knows...) m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ports system quality
to that). - And only after all involved parties finish all testing and approve the dependency upgrade, commit the port for Joe Public to finally start using it. Without at least this as a corner stone of quality control, ports will only keep rotting further, the more the applications will keep getting complex and entangled in hundreds and hundreds of dependencies. The simple fact that port builds isn't, and wasn't for a long time now, an indicator that the port really works. Or that the *ports* really work as a whole. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: Problem with nvidia-driver and X after upgrade
On Fri, 2011-08-26 at 18:51 -0400, Carmel wrote: I found the problem. I had downloaded the source files for BSD a few days ago; however, I never rebuild the kernel or world. When the nvidia driver got rebuild it was evidently using those new files. I got the answer while Googling. When trying to manually load the driver, I received this error message: kldload: can't load nvidia: Exec format error Evidently, this is a known phenomena with the nvidia-driver. This is a known phenomena with everything when having your OS sources and your live OS out of sync. So, after rebuild World/Kernel and installing same and then rebuilding the nvidia-driver, all is well again. Now, in my not so humble opinion, there should be some sort of warning in the driver dialog, or at least in the port description that warns of this behavior. It could have save3d me several hours of needless searching. Hours that I will never get back. :) Nvdia-driver is a driver, a kernel module so to say. You built the driver against kernel sources that are different from your live kernel. You got a driver that will work with kernel corresponding to those sources. What kind of warning would you be expecting there and what purpose would it serve? m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
On Tue, 2011-07-26 at 11:27 +0200, Michel Talon wrote: [ Stuff about how we should move to binary packages because Debian. ] Sure, why not kill one of the biggest strengths FreeBSD is known for while we're at it... Two questions: Who will provide the infrastructure to build me all of my packages the day/hour/moment moment I need them and constantly build me the i386, amd64, athlon-tbird optimized, k8-sse3 optimized, -O2 and -O3 optimized, intel-core optimized, and intel-p3 optimized batches for all of my machines? Who will constantly build and maintain my custom set of binary packages and all their dependencies built with the exact specific OPTIONS that I need and without the components that I don't want? Because I'm in no mood for experiencing the hell of Linux users that can't even remove ALSA from their systems and fully switch to 4Front OSS, as all of their distro's packages are built against ALSA anyway, in some cases even exclusively, with OSS support completely removed, because why not. So no, thanks, I'm one of those that are perfectly happy with my fundamentally flawed source-based ports. Take that away and you might as well as kill FreeBSD for me, and probably anyone else I know. m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
On Mon, 2011-07-25 at 09:33 +0200, Tilman Keskinöz wrote: I am ok with switching the documentation to portmaster, but i am against marking it DEPRECATED. I have been using portupdate for 10 years and it works for all my usecases. Switching to portmaster means i have to learn new -options and new error messages. Unless there is a killer feature in portmaster i don't see a reason to switch. Basically, this. I'm on the very same boat, so to reiterate it again, from my point of view: 1. Portupgrade may have bugs, sure, but none of them are critical and every one I know about can be easily worked around whenever situation arises. Some of them are so old now that most regular users probably count them as features. 2. I too have been using portupdate for 10 years (hello!) and it works for all my usecases. 3. Switching to portmaster means retraining for a different *mission critical* software, that behaves differently, and that I currently have no need for, because the former one works fine. To point out a specific examply that I see frequently in UPDATING: If you use portmaster: # portmaster -r icu If you use portupgrade: # portupgrade -fr devel/icu Ok, sure, easy task.. Hey..what? In portupgrade, -r builds all my ports recursively and updates those which are out of date, where -f forces it to rebuild every single one along the path. Clear, right? So why is this different for portmaster? Where is my -f[orce] option? Will -r always rebuild everything? Or will it never, as it is with portupgrade without -f used? IF that's the case, how can my scripts recursively rebuild only needed stuff and...damn. Sure, by that time I spent on writing this email, I might have been halfway through portmaster documentation and have my questions answered, but that's obviously not the point - I just don't need, and don't want to. While portupgrade works (and it works), I don't want spending my time on cross-checking every single usecase between portmaster and portupgrade so that my upgrade scripts can safely play with the new popular kid on the block. Unless there is something fundamentally broken with portupgrade (other than a few open PRs) that prevents it from working on a modern FreeBSD system, I don't see a point in deprecation. Especially when portmaster is *NOT* a drop-in replacement. Again, from recent UPDATING: portmaster cannot process the upgrade of www/p5-libwww from version 5 to version 6. To upgrade p5-libwww, use portupgrade instead, or deinstall p5-libwww before reinstalling: If you use portmaster: # pkg_delete -f 'p5-libwww-5*' ; portmaster www/p5-libwww If you use portupgrade, no special treatment is necessary. m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
On Mon, 2011-07-25 at 02:42 -0700, Doug Barton wrote: Change is hard. :) In fact, that's the whole point of the story, ironically or not. I have no objections to someone (or some group) choosing to maintain portupgrade. I've always said that I don't regard portmaster and portupgrade to be in competition. However if no one steps up to maintain it, portupgrade will eventually bitrot and become unusable. So for all of you saying save portupgrade! this is something you seriously need to consider. There is a difference in saving portupgrade and simply cold murdering it from behind just because it's that particular time of the month for a 'change' (cough). Believe or not, as a decade long user, I hated portupgrade from the day one, and learned to hate it even more as the code base bloated and everybody lost a slightest idea how it even holds together to the point where it is today. I can still (though barely) remember times when portupgrade was actually spending 95% cpu time on compilation and rest on fixing / saving / database / dependencies, in contrast to the current 30% compilation time + 70% portupgrade database fractal magic disco that nobody gets anymore. That said, I don't propose (nor volunteer, for the love of god) to maintain portupgrade - I just say - leave it be. As was already said before me - change the handbook/documentation, feel free to wipe all tracks of portupgrade from it, that doesn't matter even slightest to the current portupgrade user base, as we don't read that anyway. But I have machines and scripts that need to be kept up to date and will need to be for years to come, and portupgrade is the current mission critical tool for that. Change is hard, *especially* when there is nothing broken with stuff that already works. Unmaintained portupgrade is not a security threat, it's not a network service, it may have bugs that nobody cares about to fix anymore, but most people [citation needed] don't care about them, they're worked around for years, and a stable bug is almost as good as a feature, isn't it? Again, as you said - portmaster is not a replacement for portupgrade. I have no objections in its promotion to new users as the new, one and only approved way of managing ports, but this in no way cuts it for currently deployed portupgrade setups, where portupgrade works 'just fine' (and can work the same for years to come). Deprecate it, or kill it, and you will only force many current users to keep a local copy, because it's still easier than a change. Is there any win in that? m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: gnutls update fails on libchamplain
On Tue, 2011-06-07 at 20:10 +, Johan Hendriks wrote:
Hello all,
I did an cvsup of the ports tree, read /usr/ports/UPDATING.
It tells me that the new gnutls requires the following comman.
portmaster -r gnutls.
but this is the result
gmake[3]: Entering directory
`/usr/ports/graphics/libchamplain/work/libchamplain-0.8.1/champlain-gtk'
CC gtk-champlain-embed.lo
CC champlain-gtk-enum-types.lo
CC champlain-gtk-marshal.lo
CCLD libchamplain-gtk-0.8.la
GISCAN GtkChamplain-0.8.gir
/usr/include/machine/endian.h:123: syntax error, unexpected '{' in ' return
(__extension__ ({ register __uint64_t __X = (_x); __asm (bswap %0 : +r
(__X)); __X; }));' at '{'
/usr/include/machine/endian.h:123: syntax error, unexpected ';' in ' return
(__extension__ ({ register __uint64_t __X = (_x); __asm (bswap %0 : +r
(__X)); __X; }));' at ';'
/usr/include/machine/endian.h:130: syntax error, unexpected '{' in ' return
(__extension__ ({ register __uint32_t __X = (_x); __asm (bswap %0 : +r
(__X)); __X; }));' at '{'
/usr/include/machine/endian.h:130: syntax error, unexpected ';' in ' return
(__extension__ ({ register __uint32_t __X = (_x); __asm (bswap %0 : +r
(__X)); __X; }));' at ';'
/libexec/ld-elf.so.1: Shared object libgnutls.so.40 not found, required by
libchamplain-0.8.so.1
This is caused by libchamplain, for some reason, linking against itself,
or more specifically, the already installed libchamplain-0.8.so.1
library (which in turn you had linked against libgnutls.so.40).
For a quick fix (I didn't investigate further), simply remove the old
installed port, and let the new one build in clean environment:
# cd /usr/ports/graphics/libchamplain/
# make deinstall clean
# make install clean
m.
--
Michal Varga,
Stonehenge (Gmail account)
___
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: cvsup servers down
On Thu, 2011-06-02 at 14:10 +0200, David Demelier wrote: Hello, It is more likely than the cvsup servers are done for 2 weeks now and nobody complains about it. I usually use csup to fetch the ports tree but it seems I am the only one to do this :-p. Cheers, Well you're definitely not the only one :) (Like, hell, is there any other option?) Still, when such things happen, I just move up/down a digit (to cvsup3., cvsup4., cvsup5., etc) without so much complaining, you know - unless one definitely runs out of numbers... m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: nVidia BLOB driver
On Tue, 2011-04-19 at 13:44 +0200, O. Hartmann wrote: I have some questions about the state of the x11/nvidia-driver. At the moment, the stable driver is beyond version number 260.XX, but FreeBSD's port contain only version 256.53. Is there a reason why there is no more recent version in the ports? I cannot speak for the port maintainer, obviously, but no, there isn't (also this has been asked few times in the past with very little in the term of answers, if any). Anyway, me and some other people I know, have been always using the latest Nvidia drivers, usually right from day one they're released (and there have been tons of important bugfixes since 256.53 so not like it's out of boredom) and unless you run into issues that specifically affect you (this is by my knowledge extremely rare, but obviously, your own mileage may vary), there is no reason not to, even in case your goal is only a support for a new board (as if in that case you had any other option). The next question is about a problem with nVidia NV560Ti boards. The ar not supported yet by any official driver, even not by any Linux BLOB, but there seems to be a Beta driver that already has support for this kind of board. Are the efforts and costs too high to provide a BETA driver, like x11/nvidia-driver-beta? With regard to Beta drivers, they're as much official as they can be, and again, even if based just on my experience, you have very little to be afraid of (just in case you haven't tried already and are somehow discouraged by the beta flag). In the worst case scenario, if you find the beta driver not working (would be the first time for me in a decade), you can easily roll back an earlier, or any other, version (see further below). With speed that FreeBSD port of Nvidia drivers usually gets updated (read: this speed is almost approaching the speed of moving backwards in time), there is probably very little point in asking for another x11/nvidia-driver-beta branch, as those are usually relevant only for days, or weeks in the worst case, and either get further fixed (if there is still something to fix), or soon promoted to stable. So in case you're only looking for a more recent version of nvidia drivers as the port currently has (as I'm not going to argue about port maintainer's politics, whatever the current 'reasons' for not updating are), you can easily edit the port's Makefile and substitute the version for any other you want. Nvidia drivers very rarely change in terms of file structure and at this point in time (and for the past few years actually), the worst thing you're risking is leaving a few stale files behind between upgrades because of the possibility of outdated pkg-plists (and this is almost non-issue on its own). In any case - just edit your /usr/ports/x11/nvidia-driver/Makefile and replace DISTVERSION with either 270.26 (has support for your board), or the currently latest (not yet properly listed on the site) 270.41.03: DISTVERSION?= 270.41.03 then # cd /usr/ports/x11/nvidia-driver/ # make makesum # portupgrade -vfu nvidia-driver And you're done. For a time. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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] mplayer with multithreaded decoding
On Tue, 2011-03-29 at 18:53 +0200, Thomas Zander wrote: You can enable the multithreaded decoder by running run mplayer -lavdopts threads=N file (N being the number of desired decoder threads). Note that this does not apply to all stages of the playback pipeline, e.g., if playback is dropping frames due to excessive postprocessing options, this won't necessarily solve the problem. Hi Thomas, AFAIK -lavdopts threads=auto should work too in this case, though I didn't check your code yet if it's actually done there. Just mentioning it in case someone might be interested and/or wants to correct me before I get to it later today :) m. -- Michal Varga, Stonehenge (Gmail account) ___ 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
On Fri, 2011-03-18 at 19:26 +0100, Thomas Zander wrote: Dear all, I have prepared a recent snapshot for a an upcoming update for the mplayer and mencoder ports. You can find the tarball here: http://www.rrr.de/~riggs/mplayer/m20110318.tar.bz2 Please test the things that you usually do with it, I'd appreciate feedback! Thanks in advance, Riggs Thank you for your work, Thomas. Looks good on 7.4-STABLE/i386. No compile issues, x11 and vdpau playbacks both solid, subtitles work, nothing out of ordinary. Mencoder transcoding into h264 works without any issues too. m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADS UP] Ports Infrastructure Changes
On Sat, 2011-03-19 at 09:49 +0800, Martin Wilke wrote: Attached is a proposed list of ports being moved from the www category. Please review, discuss and report ommissions and mistakes. The general key to the new categories is as follows: [...] www-webapps - web apps, frameworks, libraries Just a quick thought to the 'discuss' part: Is this (above) really the best name possible? I mean world wide web-webapps sounds kind of redundant. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: sysutils/gpart: deprecated port, anyone interested?
On Wed, 2011-03-16 at 10:36 -0700, Jason Helfman wrote: Whoops :) I ran the base gpart, so not sure if it works, but I suppose it could, just not on my system. [jhelfman@eggman ~/ports/sysutils/gpart]$ sudo /usr/local/sbin/gpart show *** Fatal error: open(show): No such file or directory. -jgh gpart (the port, not the base geom tool) doesn't work that way, you're still confusing the two. sysutils/gpart is a tool for rebuilding broken partitions, so the parameter you're looking for is a device name, not show (what the error message basically told you). m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: deprecated ports
On Wed, 2011-03-16 at 07:40 +0300, Ruslan Mahmatkhanov wrote: gimpshop is pretty old and development seems stalled. The next gimp release will have gimpshop-like UI by default so i think it worth deprecating. That's almost too optimistic thing to say at the moment, as GIMP's single window interface has been in talks, like, since when, early 2009? Instead, we got this: http://libregraphicsworld.org/news.php?readmore=667 While I agree that that gimpshop itself is pretty rotten, there's no viable alternative for people willing (needing?) to use it, so backing up its deprecation with the planned (*cough*) release of GIMP 2.8 probably isn't the very best possible course in this case... At this time, there isn't even a specific release date in plans for 2.8 and even if that eventually happens, many people [citation needed] doubt that the single-UI will actually make it there (as, currently, there's not even a spec finalized for it). Just saying. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: webkit-gtk2-1.2.7 doesn't upgrade after changing python to 2.7
On Mon, 2011-03-14 at 18:26 +0200, Gritsuk Anton wrote: I upgraded and replaced my Python 2.6 to 2.7 and all packages is related of this. I use instruction from /usr/ports/UPDATING: # portupgrade -o lang/python27 lang/python26 # cd /usr/ports/lang/python make upgrade-site-packages After this update, installation/upgading of webkit-gtk2 is failed. If I replace first string in /usr/local/bin/g-ir-scanner: #!/usr/local/bin/python2.6 to #!/usr/local/bin/python2.7 my upgrade finish successful. Please, investigate this problem. I'm using python 2.7 along with webkit-gtk2-1.2.7 and there are no poblems during webkit build and/or use. From your description it seems to me more like your gobject-introspection-0.9.12_1 didn't get properly rebuilt after Python upgrade. Btw, as upgrading Python has always been a non-trivial task (I don't use upgrade-site-packages so I can't comment on that step - I found it flaky once and didn't bother anymore after), I always make sure to rebuild every Python based port during the next step before anything else (same goes with major Perl upgrades). There are not many of them directly depending on Python and it always saves from trouble like these. m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADS UP] GNU make 3.82
On Sat, 2011-03-12 at 13:34 -0800, Doug Barton wrote: On 03/12/2011 12:45, Mark Linimon wrote: On Fri, Mar 11, 2011 at 09:14:50PM -0800, Doug Barton wrote: There are way too many things happening in private around here and the only way to solve that problem is to open the doors. Would you please offer examples of decisions that you feel that way about? Clearly it would be inappropriate for me to comment publicly on things that were discussed in private, so no, I'm not going to do that. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADS UP] GNU make 3.82
On Sat, 2011-03-12 at 22:46 +0100, Michal Varga wrote: On Sat, 2011-03-12 at 13:34 -0800, Doug Barton wrote: On 03/12/2011 12:45, Mark Linimon wrote: On Fri, Mar 11, 2011 at 09:14:50PM -0800, Doug Barton wrote: There are way too many things happening in private around here and the only way to solve that problem is to open the doors. Would you please offer examples of decisions that you feel that way about? Clearly it would be inappropriate for me to comment publicly on things that were discussed in private, so no, I'm not going to do that. Sigh, I apologize, this was supposed to be sent to someone else as a part of another email, but I nicely botched it. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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] drm/dri/mesa/xorg-server update [Part 1]
On Fri, 2011-03-11 at 19:37 +0800, Martin Wilke wrote: After merging, run one of the following command, depending on which tool you use to manage your installed packages. portupgrade -af \* Is this step really necessary? This will rebuild every single installed port, which for me is, currently, like close to 1000. This probably wasn't intended. Also, -a stands for *, so one of them is superfluous in any case. m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD needs fresh Blood!
On Wed, 2011-03-09 at 22:27 +0200, George Liaskos wrote: Martin wrote: I'll cleanup all the mess and commit all stuff to the xorg-dev repo. Maybe someone have intressing to test it. but without any info where I can find xorg-dev repo, How I can test new xorg, since I don't known where this repo is? First hit points to it: http://wiki.freebsd.org/ModularXorg/7.5 Search term: https://duckduckgo.com/?q=xorg+dev+freebsd+repokp=-1kl=wt-wtka=nkt=nkk=-1ke=-1ko=skj=wkh=1kn=1kb=nkm=lku=1 You can safely add gnome3, Anyone could tell: http://www.marcuscom.com/ This one is a no brainer, as one could hardly be a FreeBSD Gnome user and never hear of Marcus (+com). But in any case, it's even as much simple as reading: http://www.FreeBSD.org/gnome/docs/develfaq.html#q3 So yes, it can't get any easier. chromium Already using a real browser, so honestly no idea about this. I'd say simple search again should suffice, but I don't have a proper background for it (like, a version or anything to start with so I would actually know what I'm looking for). and virtualbox to the list :p I'm a virtualbox user and agauin, the very first hit points me to a tarball, so I guess that's a good start: http://miwi.bsdcrew.de/2011/02/cft-virtualbox-4-0-4-for-freebsd/ Search term: https://duckduckgo.com/?q=virtualbox+4+freebsdkp=-1kl=wt-wtka=nkt=nkk=-1ke=-1ko=skj=wkh=1kn=1kb=nkm=lku=1 The point being, it's really not that hard if you just spare a minute here or there looking things up, they're not exactly trying to hide them. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: gegl
On Wed, 2011-03-02 at 16:26 +0100, Pietro Cerutti wrote: On 2011-Mar-02, 15:57, Michal Varga wrote: Out of curiosity - how is it even possible that this update made it as far as into ports tree, when it - at least as I understand from the PR - clearly doesn't work on *both* *STABLE* *supported* branches and only goes well with the very latest CURRENT? The original update doesn't cause any problems on CURRENT, 7.4-RELEASE, or 8.2-RELEASE. It does cause problems on STABLE branches. Is this guaranteed? As here with... uname -a FreeBSD 7.4-STABLE FreeBSD 7.4-STABLE #0: Sun Feb 27 22:30:14 CET 2011 ...gegl (unpatched) still fails: exp_combine.cpp: In function 'gfloat expcombine_get_file_ev(const gchar*)': exp_combine.cpp:99: error: 'log2f' was not declared in this scope gmake[2]: *** [exp_combine-exp_combine.o] Error 1 Note that 7.4-RELEASE was back in Feb 21. Or was there a change specific to 7.4-RELEASE that for some reason didn't make it into STABLE? m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: gegl
On Wed, 2011-03-02 at 18:12 +0100, Pietro Cerutti wrote: OK, I have nailed down the source of the problem. GEGL has an optional dependency on graphics/exiv2 which is not tracked by the port, i.e. exiv2 is not built as a dependency of the port, and GEGL doesn't rely on it if it doesn't find it. It turns out that the failing C module (exp_combine.c) is only compiled when EXIV is found. Thus, on a fresh system (i.e., tinderbox) the error won't appear. It will, however, on a system where EXIV is installed. Please check whether you have graphics/exiv2 installed in your system to confirm this hypothesis. I have still not decided whether to include exiv2 as a mandatory or optional dependency, cause configure doesn't handle --without-exiv2 correctly when exiv2 is installed (i.e., GEGL will be built with EXIV support in that case). Thanks for the hints, and sorry for the noise. I see, this is pretty sneaky, there's hardly a reason for you to apologize. Yes, I do have exiv2 installed, so that would explain (as others already reported). By the way - as for the mandatory dependency (though I personally am always in favor of those - makes things unified and easier to maintain), I'd say an optional dependency would fare better with the rest of the current gegl options (optional JPEG, etc). So making exiv2 optional and patching configure to handle it properly would be the cleanest approach, I guess? I've quickly checked configure and the detection looks pretty ordinary as it is now, but atm I don't have enought time to trace it over every single step, so who knows... Might be just a case of typo somewhere in there? m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Debian GNU/kFreeBSD
On Sat, 2011-02-12 at 23:33 +0330, Bahman Kahinpour wrote: Does anyone think that having an optional APT system somewhere like in the Ports Collection or ... You already know where the ... is, it's called Debian GNU/kFreeBSD. I have been told that both its users are perfectly happy with apt-system and everything else that accompanies it and then for the rest, there's this other thing called FreeBSD. Or are you offering yourself to develop a completely new, standalone and parallel ports-like/package infrastructure for FreeBSD and maintain it? If so, then seriously, good luck with that. ... can be advantageous? No. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: Port admission request
On Thu, 2011-01-13 at 14:14 +0200, Eugen-Andrei Gavriloaie wrote: So, if anybody can help me with at east an easy to follow tutorial, it would be awesome. Could this be of some help? http://www.freebsd.org/doc/en/books/porters-handbook/own-port.html m. -- Michal Varga, Stonehenge (Gmail account) ___ 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
multimedia/mencoder - why do we build it without fontconfig support?
Hi, is there a reason for having -disable-fontconfig hardcoded in mencoder's Makefile, without any option to turn it on, or even better, just leaving it on default as we already do with mplayer? I just noticed the issue while trying to render a bunch of subtitles into a movie (which is a capital crime by itself, I know, but I just really needed it on this specific occasion). And as mplayer displays subtitles happily like since forever, after a while of puzzlement I've been able to track down the offender to our mencoder's Makefile. Also, it turns out that I'm not exactly the first one to notice: http://forums.freebsd.org/showthread.php?t=18287 So the question stands - is there anything to gain by having fontconfig support forcefully disabled? After all this is mencoder we're talking about, one dependency more or less is just a drop in the ocean. And the current state really makes our mencoder kind of crippled... m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: clive
On Wed, 2010-12-29 at 17:04 -0600, ajtiM wrote: After last Update to 2.2.19 version, clive doesn't works anymore on my system: FreeBSD 8.1-RELEASE When I run it I got: clive Can't locate version.pm in @INC (@INC contains: While this is not directly related to your issue, I thought I might just mention multimedia/cclive here, in case you're not already familiar with it. It's basically a rewrite of the original clive written in c++, faster, lightweight and doesn't break all the time as original clive loved to for this or that reason (I've been a long time clive user myself and wouldn't go back). I guess you could give it a try in case you already didn't. m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster: print /usr/ports/UPDATING on update
On Sat, 2010-12-25 at 12:16 +0100, David Demelier wrote: Hi, A lot of people always forget to read UPDATING (that's normal we'll are humans). Each entry in UPDATING is like AFFECTS: users of net-mgmt/flowd so if an update of net-mgmt/flowd is available and a *recent* entry in UPDATING talks about then print the message. This can prevent a lot of breakage and useless noise on lists. What do you think ? Merry Christmas and happy holidays ! David. Or there is another possibility - find someone vocal enough to finally *enforce* all new entries to UPDATING to be machine readable. You already slightly touched the issue - but what exactly one considers recent? I've seen people that don't upgrade anything non-security related for months and some even years, when not directly required as dependency. And those are actually the cases when everything breaks horribly in the end - I guess for obvious reasons. It wouldn't be that hard to reqire all entries in updating to be in a specific and meaningful format, i.e. DATE=20101225 PORT=x11/gnome2 VERSION=2.32.1 SEVERITY=1 # 0 = informational, 1 = critical/showstopper COMMENT=Manually deinstall x11/somethingnolongercool and force recompile devel/libstupid before upgrading to this version of Gnome === Then just let upgrade tools deal with the data as they want, i.e. some really cool ones might show all entries between %my_version% and % current_version% and based on severity, either optionally let users skip over the warning - * /This application no longer ships with skype-voice-whatever plugin, please recheck your configuration/ doesn't really count as show stopping - versus - * Don't allow upgrade process to continue unless user explicitly confirms Yes, I've totally read that and just finished all the steps required for cases where there is guaranteed that upgrade *WILL* break without following those steps first. Something like this would finally make UPDATING an integral part of any upgrade process, not just some half-forgotten text file that one *should* keep an eye on - but usually only after all hell broke loose. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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] mplayer / mencoder port update
On Sat, 2010-11-13 at 03:22 +0300, Anonymous wrote:
Can you try to replace
#ifdef __FreeBSD__
with
#ifdef __FreeBSD__ __FreeBSD_version = 800097
Alternatively, just hide the patch under ${OSVERSION} = 800097.
Just my 2 cents:
Wouldn't be easier to simply made the patch optional via OPTIONS
(defaulting to off) and forget about it?
For example, I too have no use for it, as I don't prefer applications
messing with my mixer and thus run mplayer with -sotfvol. And seriously,
even then, for the past 10 years of pretty heavy mplayer usage - I
changed volume in it for like.. three times, ever (probably by
accident).
So for me, this is a patch that's not part of $Upstream, does absolutely
nothing I need, does even less for 4Front OSS users, and is already
known to break stuff for someone (the last point being somewhat
significant).
Please, don't include it by default for everyone.
m.
--
Michal Varga,
Stonehenge (Gmail account)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Portmaster 3.1 upgrade
On Sun, 2010-10-31 at 17:57 +0100, Alexandre wrote: I read in /usr/ports/UPGRADING the instructions to properly upgrade PORTMASTER 3.1. It is written to do : # pkg_delete -f portmaster* The wildcard ( http://en.wikipedia.org/wiki/Wildcard_character ) is interpreted by your shell and expanded into a list of matching files from your current working directory, then sent as a parameter to pkg_delete. What you were probably trying to do was either pkg_delete -f portmaster\* or pkg_delete -f portmaster* m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Portmaster 3.1 upgrade
On Mon, 2010-11-01 at 04:18 +1100, andrew clarke wrote: UPDATING should probably be amended upstream to correct this... Regards Andrew While I'm certainly no authority on the issue, I think that's the wrong approach and generally (really not speaking about any specific case) - people, or in this case, system administrators, should know how to operate their working environment and don't just blindly enter commands as they found them, without trying to understand what will happen next and/or how it will get interpreted. Otherwise we will keep ending with things like this particular example from UPDATING: 20100518: Please manually delete apache-2.\* if installed _before_ updating using either portmaster or portupgrade I think there's no need to explain why such dumbing down (even though in a good spirit) can lead to serious issues, or in this case - if someone actually tries to remove the apache-2.\* package, only to find there is no such thing. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: Web feed for /usr/ports/UPDATING
On Fri, 2010-09-24 at 11:08 -0700, Charlie Kester wrote: On Thu 23 Sep 2010 at 20:39:25 PDT Alexander Kojevnikov wrote: Hi list, Since the only SUBJ I could find [0] is long since dead I created my own: http://updating.versia.com/ Any feedback is welcome. Cool idea! Count me as another subscriber. +1, Subscribed -- Michal Varga, Stonehenge (Gmail account) ___ 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
New NVIDIA 256.53 driver with important fixes
For those interested, there is a new graphics driver available from nvidia with some rather important fixes: http://www.nvidia.com/object/freebsd-x86-256.53-driver.html For quick and dirty installation/testing, edit distversion as: DISTVERSION?= 256.53 in /usr/ports/x11/nvidia-driver/Makefile run `make makesum` and reinstall your driver. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: nvidia-driver 256.35 released
On Wed, 2010-06-23 at 01:09 +, Alexey Dokuchaev wrote: Sure, I will take care of plist issues upon the upgrade. What is more important right now is driver stability issues people had been having. I must rely on other people testing since I was not able to reproduce most of them in my local environment. ./danfe Well, I can't comment on the stability issues as I didn't have any, but if it helps, just a quick success report to the pool: Latest 7.3-STABLE, i386, 256.35 on GeForce GT240: Tested pretty much everything from native OpenGL, through linuxulated games (Quake 4, ET), vdpau acceleration, DirectX-to-OpenGL translated Windows games through Wine, and finally some native Windows OpenGL through VirtualBox (whose current OpenGL implementation is pretty flaky on its own anyway), and so far, everything seems to be working rock solid, here and there with some minor performance increases. Could have been much worse, I guess. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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 upgrade perl 5.8 to 5.10?
On Wed, Jan 20, 2010 at 1:54 PM, Helmut Schneider jumpe...@gmx.de wrote: [...] Currently the only solution seems to remove perl.5.8 which as a result deletes all dependencies which requires *all* ports to be reinstalled. No way, only if you decide to deinstall everything recursively. What about: # pkg_deinstall -vfu perl-threaded-5.8.9_3 # portinstall -v lang/perl5.10 # portupgrade -vfu p5\* (Also, cross-checking with /usr/local/bin/perl-after-upgrade helps with some other specific cases). m. ___ 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 upgrade perl 5.8 to 5.10?
On Wed, Jan 20, 2010 at 2:58 PM, Helmut Schneider jumpe...@gmx.de wrote: # pkg_info -R perl-threaded-5.8.9_3 | grep -v ^p5 Information for perl-threaded-5.8.9_3: Required by: amavisd-new-2.6.4_4,1 apache-2.2.14_5 bsdpan-SNMP-Extension-PassPersist-0.03 gamin-0.1.10_3 gio-fam-backend-2.22.4 glib-2.22.4 mailgraph-1.14_2 nagios-plugins-1.4.14,1 net-snmp-5.4.2.1_6 pango-1.26.2 razor-agents-2.84 rpm2cpio-1.2_2 rrdtool-1.3.9 # (Also, cross-checking with /usr/local/bin/perl-after-upgrade helps with some other specific cases). I did so when I upgraded from 5.8.8 to 5.8.9. I finally found myself doing a portupgrade -af. :) I'm not a heavy Perl user, but I don't remember anything ever melting too much, while doing it this way. Of course, there are things like irssi, that break -every time- you reinstall Perl (even the same version), but one gets used to it quickly. Then there is the rest that probably only execs some scripts with Perl and doesn't care about your versions (much). Majority of your, or mine, installed ports have Perl only as an inherited dependency and never directly use it, so -af is a bit overkill in such cases, i mean: pkg_info | wc -l 805 Whew. So even when you're switching near-major versions, recompiling p5-* and maybe some of those in your list (I'd randomly pick, say amavisd, bsdpan- and razor) should be enough, the fallout will be minimal, if any (and if so, you just rebuild that one more that still fails). Nevertheless, your list in't that extensive, recompiling all of it shouldn't take more than half an hour, that's still a bit cheaper than -af :) m. ___ 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 upgrade perl 5.8 to 5.10?
# pkg_info | wc -l 457 # And this machine is even my package-building station! Anyway, portupgrade -af took 45 minutes. *g* Well, it's a dedicated blade after all :) And those 8 cores seem pretty nasty, I'm envious. That 800+ installed ports are for a regular desktop system, CPU: AMD Phenom(tm) 8450 Triple-Core Processor (2109.74-MHz 686-class CPU) Cores per package: 3 just things like xul/firefox, or webkit alone take an hour to build. Think of 2 to 3 days to recompile everything from scratch. And that's only for a Gnome desktop setup, throw in another KDE environment to the mix and their family of applications and you can round that to a week (maybe slightly less if you leave the machine running completely dedicated). While your blade would cut that time down considerably, it still wouldn't be in minutes anymore :) m. ___ 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 upgrade perl 5.8 to 5.10?
Well, it's a dedicated blade after all :) And those 8 cores seem pretty nasty, I'm envious. Well, afaik I even cannot use more than one CPU when building ports. There were plans/rumors that this would change. Does anyone know more about it? Sure you can, as Boris (below) linked, this happened long time ago, especially: You don't need to do anything to enable the new feature. Whitelisted ports will automatically make use of all processors available in your computer. Most large ports I have seen (and use) luckily take advantage of all available processors during build (which completely sucks for desktop systems, but then, you normally shouldn't do that on a station where you try to work, so I'm fine with that). There's no way you'd be able to build 450 ports in 45 minutes if you were using only one CPU/core. It has happened: http://lists.freebsd.org/pipermail/freebsd-ports/2009-March/053736.html I believe *dependencies* of a port will be compiled using one process (and thus CPU) at a time, however. Interesting, are you sure this really happens? At least I understand you mean that - let's say - when i choose to compile, i.e. www/webkit directly, it will use all available processors (which it does, all the time), but when I try to compile, say, www/epiphany, which pulls www/webkit as a dependency, it will get built without MAKE_JOBS_SAFE, locked to a single processor? I can test in a short while if that's really the way, just asking, if I got you right.. m. ___ 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
Nouveau Starts Dropping Non-KMS Support
Basically, this: http://www.phoronix.com/scan.php?page=news_itempx=Nzg3MA ---snip--- Red Hat's Ben Skeggs though has started deleting non-KMS code that is trimming this NVIDIA X.Org driver by thousands of lines of code. While user-space mode-setting will no longer work, kernel mode-setting is the superior solution and is the future. Intel had also recently dropped support for user-space mode-setting. ---snip--- Does anyone (Robert, probably) know, how this will affect FreeBSD in the near and well, eventually distant future? I mean, I guess this one typical linux user's comment from Phoronix discussion probably sums it all, but still, it's hard not to laugh (hysterically): Well, If portability stands in the way of progress, I say to hell with portability. Well anyway, are we going to lose Nouveau yet before we even properly got it, or are there any plans to workaround this issue? I mean, last I heard KMS in FreeBSD is not going to happen for years (if ever), so what other options are still open? m. ___ 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: boost 1.41 and net-p2p/deluge
On Wed, Dec 30, 2009 at 6:47 PM, Howard Goldstein h...@queue.to wrote: Michal Varga wrote: After the recent boost upgrade to 1.41, net-p2p/deluge needs to be recompiled to actually start, otherwise one just gets a nice crash/deadlock (I didn't investigate as I already remember the exactly same issue with previous boost upgrade, so went directly for recompilation). Thanks for posting this. Just to be on the safe side I'm rebuilding gimp and some other friends that weren't rebuilt after the boost update. Same for me. While GIMP and abiword seemed to be starting fine, i don't want to risk crashing it when I execute some plugin/extension that actually uses boost and well, lose my work :) On the other hand, that issue may be specific to boost-python-libs, deluge is the only app I have that actually uses it, so the C side of boost *might* be innocent here. m. ___ 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: mplayer from SVN
On Tue, Dec 29, 2009 at 7:05 PM, Frank Staals fr...@fstaals.net wrote: On 12/29/09 14:31, Lars Engels wrote: Quoting Frank Staals fr...@fstaals.net: I know it is not as nice as simply having a port. But if you realy need the svn-releases for some feature XYZ it may be a (temporary) solution. Are there any killer features missing in our old version from ports? I don't really know. The reason that I used svn snapshots in the past was that my machine in combination with the mplayer port was unable to decode relatively high res h264 video while with the svn version there were some improvements which did make it possible. But that is a long time ago. Related to that, VDPAU ( http://en.wikipedia.org/wiki/VDPAU ) is definitely the killer feature, though I'm not sure how well (and if) it works on FreeBSD. For what I know, it works miracles on Linux (well, at least Linux people say that). Quick google turned out this, so I guess it's a start: http://forums.freebsd.org/showthread.php?t=4756 For anything else killer-grade, I'm not really sure, but since the dawn of time, mplayer code base has always been a bit flaky (well, a bit itself is a bit too generous here). I guess all of us keep at least one other backup movie player (Gnome's Totem, XINE before that, etc.) for files that make mplayer die horribly in a ball of fire (recent youtube formats, I'm looking at you!) and vice versa - so one can reasonably assume that sticking to a 3-year old code base is not the very best we could do here and in the long term, unmanageable. It will only get worse.. 4 years? 5 years? Eventually other apps that use mplayer as their backend will start to fail, dtto various mencoder frontends (I'd say 'video editing software', if we only had any), and we will get stuck with gstreamer-powered crap (ok, not exactly bad, but even now in 2009, it's light years far from anything that 3-year old mplayer can do, and, you know, even a bad timed sneeze or an unfavorable lunar phase can make Totem crash). Anyway, my point was - if there is anyone planning on bringing mplayer up to date - either the main port, or as a set of new -devel ports, please, please, please, do it soon. Even from strictly political view - having something as hight profile as THE movie player on *nix built from a 3 year old code base just looks bad and only adds fuel to various Linux vs. BSD piss contests. The whole situation needs to be dealt with*. m. (* Sooner, or later.) ___ 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: mplayer from SVN
On Tue, Dec 29, 2009 at 9:03 PM, Sean C. Farley s...@freebsd.org wrote: I am jumping randomly into the thread. If we want to use some type of release for MPlayer based upon a snapshot from svn, how about using the same snapshot as used in Fedora (actually RPM Fusion)[1]? It has the advantages of already being created, tested(?) and easier to track bugs that users of Fedora may have already faced. This is an interesting idea, though there may be one issue. Do we know how Fedora people create those snapshots? Let's say, hypothetically, there are two different output drivers in mplayer's SVN tree - let's name them CoolOutput_Linux and CoolOutput_BSD. Can we be sure that Fedora guys simply don't strip out the parts that they can't/will never use, so we end up with a snapshot package that lacks CoolOutput_BSD? m. ___ 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
boost 1.41 and net-p2p/deluge
After the recent boost upgrade to 1.41, net-p2p/deluge needs to be recompiled to actually start, otherwise one just gets a nice crash/deadlock (I didn't investigate as I already remember the exactly same issue with previous boost upgrade, so went directly for recompilation). Anyway, just an idea - shouldn't be those apps that depend on boost also bumped, to prevent issues like these? (again, might need some more investigation, this is just a quick notice) m. ___ 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: mplayer from SVN
On Mon, Dec 28, 2009 at 3:47 PM, eculp ec...@encontacto.net wrote: I have a port for building the latest exported snapshot from SVN, but it requires manual editing because the extract dir changes daily. Hi, does your port deinstall cleanly ? - I would love to use an mplayer version newer than the 3-year old RC. If yes, I would very appreciate if you could send it to me :) I'll go the old Me Too route. I like the idea very much. Look forward to using it. Does anybody know why are we still using 3-year old version? I mean, mplayer (and its brother mencoder) are one of THE killer apps on *nix, and I see obscure 20-year old games being updated more often in the ports collection. Did something specific happen to mplayer that it ended in this state? I could hardly believe the reason is only that upstream decided to stop releasing tarballs, after all, this never stopped anybody in creating -devel ports. Why was mplayer different? Is there any background info? s. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: HEADS UP: GNOME 2.26 available for FreeBSD
On Tue, Apr 14, 2009 at 12:24 PM, Dmitry Morozovsky ma...@rinet.ru wrote: On Tue, 14 Apr 2009, Michal Varga wrote: Yes, seahorse shows me two keyrings; however, deleting login one does not fix the situation: if in the Terminal I try to open tab which ssh's to outer host, I immediately got the popup with There was an error creating the child process for this terminal nothing in this tab is started, and tab is just hanging. Out of curiosity, unrelated to your issue - if this is about interactive ssh [shell] session, do you mean Gnome Terminal? I wasn't aware it can do anything on its own with ssh, normally I run the regular ssh client inside. How do you ssh directly from Gnome Terminal (if that's the one you mean) with gnome-keyring/seahorse capabilities? m. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: HEADS UP: GNOME 2.26 available for FreeBSD
On Tue, Apr 14, 2009 at 5:34 PM, Dmitry Morozovsky ma...@rinet.ru wrote: On Tue, 14 Apr 2009, Michal Varga wrote: Yes, it's Gnome Terminal, see $SUBJ ;-) I just filled 'ssh -e none host' in execute command field. Before upgrade to 2.26 everything is worked like a charm -- on a first external connect, seahorse popup appears, asks me for a passphrase, and subsequent external sessions works automagically. I'm still puzzled with that, by execute command field i guess you mean [x] run a custom command instead of my shell in gnome-terminal preferences. Bud where'd you get the ssh/seahorse functionality? Let's assume the 'ssh' will run the first ssh in path, that is by default $ which ssh /usr/bin/ssh $ ssh -V OpenSSH_5.1p1 FreeBSD-20080901, OpenSSL 0.9.8e 23 Feb 2007 But where does your seahorse powered ssh client come from? m. ___ 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
gnome-session - half a year later, almost there
Hi guys, I know that FreeBSD Gnome team has spread pretty thin in past few months, but just in case (or as a reminder) - is someone from the Gnome staff keeping an eye on this issue? http://bugzilla.gnome.org/show_bug.cgi?id=552387 Basically, the single biggest Gnome regression (ever?) is back to its pre-2.24 state, it probably wouldn't hurt having it back in FreeBSD before 7.2 comes out (if that's still possible, and if there is time, resources for it, etc). m. ___ 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
[PATCH] gnome-session with session support (duh)
As noted in my previous email today ( http://lists.freebsd.org/pipermail/freebsd-gnome/2009-April/022096.html ), gnome-session 2.26.0.90 is out, with working session save/restore, the one that has been exterminated with introduction of Gnome 2.24 and created an usability nightmare for many desktop users. Since moments later the ports tree has been frozen for the upcoming FreeBSD 7.2 release, here is a little local patch in case the new changes won't make it there for a while: (gmail will probably break the lines at 80 chars, does anyone know how to prevent this?) --snip--- --- Makefile 2009-04-10 07:56:18.0 +0200 +++ Makefile.new 2009-04-13 17:34:24.0 +0200 @@ -7,7 +7,7 @@ # PORTNAME= gnome-session -PORTVERSION= 2.26.0 +PORTVERSION= 2.26.0.90 CATEGORIES= x11 gnome MASTER_SITES= GNOME \ http://www.marcuscom.com/downloads/:local --- distinfo 2009-04-10 07:56:18.0 +0200 +++ distinfo.new 2009-04-13 18:18:05.0 +0200 @@ -1,6 +1,6 @@ -MD5 (gnome2/gnome-session-2.26.0.tar.bz2) = e17dbce7446b3e42fac2b1cea7dedffd -SHA256 (gnome2/gnome-session-2.26.0.tar.bz2) = 0a161c419718b83e18200fe51e7e5f827b9b72a5ef055782c8c896c550a7881b -SIZE (gnome2/gnome-session-2.26.0.tar.bz2) = 829541 +MD5 (gnome2/gnome-session-2.26.0.90.tar.bz2) = b715b1de0de24a49eb91b41a6731919b +SHA256 (gnome2/gnome-session-2.26.0.90.tar.bz2) = d13fd92dd85286eee8d322a9f4a91dbd464bff3507f3d300b7f829d45e31d9fb +SIZE (gnome2/gnome-session-2.26.0.90.tar.bz2) = 834138 MD5 (gnome2/freebsd-splashes-gnome-2.18_1.tar) = 80eb8c52fcf9fe977e0bf8ed48b85fe5 SHA256 (gnome2/freebsd-splashes-gnome-2.18_1.tar) = fcca0f6eb759a4ef0211ecd61340f84ce8ad4d7493f725ac8613724faadbb508 SIZE (gnome2/freebsd-splashes-gnome-2.18_1.tar) = 1630720 --snip--- I've been testing .90 for a while and it seems to be working just fine (though, I guess anything could be considered fine in opposition to the whole functionality missing). So far no problems encountered, so those who can't wait for the proper introduction (be it 2.26.0.90 or 2.26.1) can use these steps to upgrade to the .90 version now: # cd /usr/ports/x11/gnome-session # fetch http://varga.stonehenge.sk/temp/gnome-session-2.26.0.90.patch # patch gnome-session-2.26.0.90.patch # rm -fv *.orig gnome-session-2.26.0.90.patch # portupgrade -vRu gnome-session (portmaster users should replace the last step with proper portmaster equivalent, of course) Restart Gnome, start using the desktop as you did back in 2.22. In case you find something seriously wrong with .90, you can go back to original 2.26.0 any time later with basically the same steps, just answer 'yes' when asked for patch reversal: # cd /usr/ports/x11/gnome-session # fetch http://varga.stonehenge.sk/temp/gnome-session-2.26.0.90.patch # patch gnome-session-2.26.0.90.patch # rm -fv *.orig gnome-session-2.26.0.90.patch # portupgrade -vfu gnome-session m. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: HEADS UP: GNOME 2.26 available for FreeBSD
On Tue, Apr 14, 2009 at 3:13 AM, Dmitry Morozovsky ma...@rinet.ru wrote: Dear Joe Marcus, DM JMC What versions of gnome-keyring and seahorse do you have? DM DM ma...@revamp:/usr/ports pkg_info | egrep 'gnome-keyring|seahorse' DM gnome-keyring-2.26.0 A program that keeps passwords and other secrets DM seahorse-2.26.0 GNOME application for managing encryption keys (PGP, SSH) After portupgrade -f seahorse gnome-keyring and reboot still the same effect... Of course, I can wipe packages installed and set it up from scratch, but I would prefer a bit safer way if at all possible ;-) Well, I have no idea what a Terminal remote login in this particular context is, so this may not be of any help, but I've seen this issue before: Before the upgrade, I had once pop-up asking for my key passphrase, then let me use this private key during my (home) session without further asking.. Now, when I try to connect to the host which even possibly want to check whether I want to present some key there, I got the pop-up. I even checked that I can connect to the host in question using plain xterm, and have usual password qiery. I've been in similiar situation some time ago, when new gnome-keyring/seahorse (it started with one of the recent versions, don't remember exactly when, but definitely before 2.26 was introduced) for some surely interesting reason insisted on creating a very own keyring every other reboot - while originally you were using one default keyring (let's call it default) for storing your passwords, now gnome-keyring kept creating a new one named login and always set it as the default one. That login keyring was even more special in that that nothing stored in it ever worked, it still kept asking for passwords and even then was not able to use them (and lost them on the next reboot anyway.. Maybe that's a feature, don't know, don't care). I've run into this on a few different machines, every time I needed to open 'seahorse', get to Passwords tab, delete the login keyring, set the original default as the default keyring (first time I wiped them all and created a clean one to be sure, but as it turned out later, this wasn't needed), after that, passwords worked fine again. This procedure again and again for a few days/reboots, until seahorse miraculously stopped this madness and let my default keyring be, well, default (yes, just like that). Anyway, if you weren't there yet, check seahorse gui for what keyring are you really using, maybe you've hit the same issue with the login stupidity.. m. ___ 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: [PATCH] gnome-session with session support (duh)
Additional small patch (attached) for ConsoleKit is needed for 'shutdown' from within Gnome to work with gnome-session 2.26.0.90. Logout alone works even without applying this patch. Diff is against consolekit-0.3.0_6 (latest). # cd /usr/local/etc/dbus-1/system.d/ # fetch http://varga.stonehenge.sk/temp/ConsoleKit.patch # patch ConsoleKit.patch # rm -fv *.orig ConsoleKit.patch Relog Gnome, shutdown works again. m. ConsoleKit.patch Description: Binary data ___ 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: vlc mplayer lost window borders and controls
On Tue, Jan 27, 2009 at 7:05 PM, Garrett Cooper yanef...@gmail.com wrote: Have you read / followed through UPDATING yet? Everything based on xcb has to be rebuilt (I'm still working on fixing my forked up copy of xchat2). -Garrett Sure, rebuilt the whole xcb path (and much more to that as I was wiping out lots of old shared libs at the same time, so there actually isn't much that wasn't freshly (re)built right after the xorg/xcb upgrade) and the gmplayer problem is still present. ___ 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: vlc mplayer lost window borders and controls
On Mon, Jan 26, 2009 at 8:20 PM, icemaca icem...@gmail.com wrote: back to the drawing board then. still baffled why mplayer too Dunno if this is your case, but you may be confused by the way mplayer GUI is launched. Normally, mplayer runs a GUI-less version of mplayer, and as you have been using gnome/menu/icons before, you may not be aware of this, my guess. GTK version of mplayer is launched via gmplayer (that's pretty much the one that your icons were using). Well, and since the recent xorg upgrade, that one stopped working, at least for me: $ gmplayer MPlayer 1.0rc2-4.2.1 (C) 2000-2007 MPlayer Team CPU: AMD Phenom(tm) 8450 Triple-Core Processor (Family: 16, Model: 2, Stepping: 3) [...] [ws] Error in display. [ws] Error code: 10 ( BadAccess (attempt to access private resource denied) ) [ws] Request code: 146 [ws] Minor code: 1 [ws] Modules: (NULL) Check in your terminal if that's not the case for you too, that would explain 'the icons not working'. Still, the GUI-less version runs fine. ___ 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
gnome-session 2.24 (upstream) mess
Hello guys, I noticed that Gnome 2.24 was commited today along with gnome-session 2.24, so I need to ask - how did FreeBSD Gnome team decide to deal with the recent session management fuckup? I mean this: http://np237.livejournal.com/22014.html http://bugzilla.gnome.org/show_bug.cgi?id=552387 https://bugzilla.redhat.com/show_bug.cgi?id=471980 ...etc, basically any OS/distribution that adopted 2.24 has been heavilly bitten by this major regression (try google a few discussions just for the lulz factor, though seriously, the whole situation is not that much humorous) and so far I heard that only Gentoo ships (probably somewhat modified/patched, though I'm not a Linux user and would need to check their repos first) gnome-session 2.22 to address it. Anyway, my question is (while i'm still syncing the ports) - was the issue addressed on FreeBSD's side, if not, are there any plans to address it really soon, and if not (god save us), can someone please at least put a neon blinking warning in UPDATING? I've seen a few Linux early adopters of Gnome 2.24 on a verge of suicide then they learned that session management (as we know it) has been shot in the head, without any replacement in sight.. m. ___ 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: gnome-session 2.24 (upstream) mess
On Sat, Jan 10, 2009 at 9:01 PM, Doug Barton do...@freebsd.org wrote: Michal Varga wrote: Hello guys, I noticed that Gnome 2.24 was commited today along with gnome-session 2.24, so I need to ask - how did FreeBSD Gnome team decide to deal with the recent session management ... FYI we don't use that kind of language on our lists. In any case it seems something like this should be in the pkg-message so that users are aware. Doug You're right, I apologize for the somewhat improper language, It's been just stuck in my head since I've been debugging this behaviour for a friend and came across the whole issue, then immediately started tearing my hair out (obviously, I'm a heavy session user too). The whole situation made quite a number of people angry, and not just because of missing my windows won't pop back when i relog. With this, uhm, politely said, regression (at least on Ubuntu where I've been pointed to to check it), fully gnome-aware applications now simply crash when you log out of Gnome (take with a grain of salt - I didn't check if they are actually sig-terminated, or if they shut themselves semi-correctly when X server terminates, or anything deeper). But the outcome is that the next time you log back and restart your applications manually, you get a nice show of It seems that Galeon crashed last time, It seems that Evolution crashed last time, poink, poink, poink... Or if you have an application with unsaved changes or crunching some data, it is not able to prevent logout and it's closed (with a hammer) too. The whole situation makes one want to cry, some online discussions about it are a pretty nice evidence of that. Still you are right, I'll watch my language next time and prevent any similar slips. (And, Jeremy - I'm sorry I didn't take part in testing this particular release from MarcusCom, I've been doing it for years and somewhat grew too lazy over time.. At least you can be sure you will definitely have one tester back for 2.26 :) m. ___ 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: linux-enemyterritory
On Mon, Dec 29, 2008 at 1:34 PM, Ricardo Jesus ricardo.meb.je...@gmail.com wrote: No need for a patch. It's simply a matter of sysctl. Take a look here: http://linux-bsd-sharing.blogspot.com/2008/12/tip-enable-sound-on-enemy-territory.html Interesting, so it actually got fixed at around the same time. My apologies for not checking first, I was assuming that the problem is still there simply based on the error message in the original post. (by the way, the linked tip is missing a 'sysctl' command in step 2) m. ___ 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: linux-enemyterritory
On Tue, Dec 23, 2008 at 1:48 AM, Garrett Cooper yanef...@gmail.com wrote: On 12/22/08, Gonzalo Martínez-Sanjuan Sánchez g.marti...@pcbsd.es wrote: Hi there! I have a problem with the enemyterritory port using linux compat layer. The game has no sound. The only problem I get its this messagge: --- sound initialization --- /dev/dsp: Invalid argument Could not mmap /dev/dsp Have someone any other problem like that??? Is that somekind of already known bug? Yep, for a long time, sort of. Though I haven't been playing ET for quite a while, I'm pretty positive that the patch linked here will solve your problem, hopefuly it can still be applied cleanly these days: http://lists.freebsd.org/pipermail/freebsd-current/2007-June/073454.html Dunno why it never got commited/properly fixed, maybe you can push someone to finish it this time :) m. ___ 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 get Flash7 working!
On Thu, 2008-01-17 at 08:50 +0100, Alexander Leidinger wrote: There's a different thread about flash and [EMAIL PROTECTED] reported there that the plugin is loaded by firefox but crashes. I've also seen reports that it doesn't crash, but I think those people where just lucky and didn't use the subset of flash which triggers the crash. You can crash Flash9 on FreeBSD any time just by visiting youtube.com and playing any random video, 100% success guaranteed. By the way, Flash9 is buggy like hell even when running natively on Linux, I can't confirm that by myself, but have some old coworkers in various web development companies and they say their clients complain every other day that their new fancy Flash9 presentations (thus requiring Flash9 plugin) crash Linux browsers like stock market in 1929. Of course, it's still much worse under Linuxulator. m. -- Michal Varga [EMAIL PROTECTED] Stonehenge ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INDEX breakage
On Sat, 2007-10-27 at 19:42 +, R.Mahmatkhanov wrote: Good day! A couple of days ago i had meeting this error while doing make index: # make index Generating INDEX-7 - please wait..cut: stdin: Illegal byte sequence Makefile, line 32: warning: /usr/bin/cut -f 1 -d '|' /usr/ports/audio/mbrolavox/voices.conf returned non-zero status erserver-1.2_4: /usr/ports/databases/postgresql-server non-existent -- dependency list incomplete === databases/erserver failed *** Error code 1 1 error Don't know if this may be related, but when its about ports and dependencies - for last two days I'm seeing these errors when trying to portinstall various ports (gimp, tomboy for example, but there were probably more of them, I ran into this on another box just today): portinstall -v tomboy --- Session started at: Sat, 27 Oct 2007 18:04:26 +0200 [Gathering depends for deskutils/tomboy ..[snip]--- Session ended at: Sat, 27 Oct 2007 18:04:42 +0200 (consumed 00:00:15) /usr/local/lib/ruby/1.8/set.rb:257:in `merge': value must be enumerable (ArgumentError) from /usr/local/sbin/portinstall:838:in `get_all_depends' from /usr/local/lib/ruby/1.8/set.rb:189:in `each' from /usr/local/lib/ruby/1.8/set.rb:189:in `each_key' from /usr/local/lib/ruby/1.8/set.rb:189:in `each' from /usr/local/sbin/portinstall:837:in `get_all_depends' from /usr/local/sbin/portinstall:838:in `get_all_depends' from /usr/local/lib/ruby/1.8/set.rb:189:in `each' from /usr/local/lib/ruby/1.8/set.rb:189:in `each_key' ... 35 levels... from /usr/local/lib/ruby/1.8/optparse.rb:785:in `initialize' from /usr/local/sbin/portinstall:221:in `new' from /usr/local/sbin/portinstall:221:in `main' from /usr/local/sbin/portinstall:2175 --- Session started at: Sat, 27 Oct 2007 18:06:22 +0200 [Gathering depends for graphics/gimp ...[snip]--- Session ended at: Sat, 27 Oct 2007 18:06:36 +0200 (consumed 00:00:14) /usr/local/lib/ruby/1.8/set.rb:257:in `merge': value must be enumerable (ArgumentError) from /usr/local/sbin/portinstall:838:in `get_all_depends' from /usr/local/lib/ruby/1.8/set.rb:189:in `each' from /usr/local/lib/ruby/1.8/set.rb:189:in `each_key' from /usr/local/lib/ruby/1.8/set.rb:189:in `each' from /usr/local/sbin/portinstall:837:in `get_all_depends' from /usr/local/sbin/portinstall:838:in `get_all_depends' from /usr/local/lib/ruby/1.8/set.rb:189:in `each' from /usr/local/lib/ruby/1.8/set.rb:189:in `each_key' ... 30 levels... from /usr/local/lib/ruby/1.8/optparse.rb:785:in `initialize' from /usr/local/sbin/portinstall:221:in `new' from /usr/local/sbin/portinstall:221:in `main' from /usr/local/sbin/portinstall:2175 os details: FreeBSD 7.0-BETA1 #0: Sun Oct 21 15:44:29 CEST 2007 i386 portupgrade-devel-2.3.1 ruby18-bdb-0.6.2 db41-4.1.25_4 perl-5.8.8 ruby-1.8.6_2,1 Everythings is fully cvsupped to the latest, pkgdb, portsdb rebuilt a dozen of times, latest index fetched, etc. Any hints, ideas? m. -- Michal Varga [EMAIL PROTECTED] Stonehenge ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Moving to a more recent linux base, when?
On Thu, 2007-08-23 at 21:01 +0200, Roman Divacky wrote: let me clarify things a little. the 2.6 support in 7-current is good enough. I am not aware of panics and the only does not work because of 2.6 program I know is java which I have sent a patch to kib@ to commit it (so it should be in before 7.0R) Well, just for the record, Enemy Territory stopped working with 2.6 for me, but I can live with that (Doom 3 runs still fine, for example). On my -CURRENT desktop, I have 2.6 support enabled from the first day of commit and never plan to go back, not just for one game or even Java. From the perspective of a common everyday desktop user, I'd call current 2.6 support fine enough, and we are talking about 7.0 that's not even out yet. Anyway, good job, Roman and the rest of the team. Just my two pieces of a random currency. m. -- Michal Varga [EMAIL PROTECTED] Stonehenge ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
