Re: CFT: CentOS 6.6 base + userland
On 11/05/2014 00:07, Johannes Meixner wrote:
> On Tue, Nov 04, 2014 at 04:14:05PM -0500, Kris Moore wrote:
>> Does running skype require the lemul branch still, or what minimum
>> version of FreeBSD?
> It's a variant of Skype 4.2.0.13 which disguises itself as 4.3.0.37. So,
> actually, neither (yet). It's been floating around on IRC, mostly.
>
>
>
I've merged in the patch here. It mostly works, it was just missing this
port for www/linux-c6-flashplugin11 to function:
https://github.com/pcbsd/freebsd-ports/tree/master/graphics/linux-c6-gdk-pixbuf
I've tested skype4. It starts up, but I can't seem to connect. Might be
crappy hotel wifi though. I do see a bunch of these on the console:
linux: pid 10892 (skype): ioctl fd=25, cmd=0x8b01 ('\M^K',1) is not
implemented
This is on 10.1-RC4 freebsd world / kernel.
--
Kris Moore
PC-BSD Software
iXsystems
signature.asc
Description: OpenPGP digital signature
Re: CFT: Update to xf86-video-ati 7.5.0
Jean-Sébastien Pédron wrote: Hi! Before updating xf86-video-ati to 7.5.0, we would like some people to try it out. The reason is that 7.4.0 was crashing for several users, so we want to be sure it's fixed in 7.5.0. Here's patch: https://people.freebsd.org/~dumbbell/graphics/ports-xf86-video-ati-7.5.0.patch To apply it: cd /usr/ports patch -p1 < /path/to/ports-xf86-video-ati-7.5.0.patch Then update x11-drivers/xf86-video-ati with your method of choice. What we're especially looking for is report of successful or failed startup of the X server. With 7.4.0, the server would crash during startup. But with 7.5.0, none of us could reproduce the problem. When you're finished, you may restore your vanilla ports tree: cd /usr/ports patch -p1 -R < /path/to/ports-xf86-video-ati-7.5.0.patch find x11-drivers/xf86-video-ati -name "*.orig" -delete Thank you for your help! Strange problem. monitor doesn't wake up after all night sleep, moreover, when I tried to connect my tv on hdmi I had 256 colors instead of 16 million and no hardware acceleration at all. ports tree is as new as yesterday. btw, Jean-Sebastien, xf86-video-ati-ums doesn't work at all, just blank screen: [39.160] (II) AIGLX: Screen 0 is not DRI2 capable [39.160] drmOpenDevice: node name is /dev/dri/card0 [39.160] drmOpenDevice: open result is 12, (OK) [39.160] drmOpenByBusid: Searching for BusID pci::01:00.0 [39.160] drmOpenDevice: node name is /dev/dri/card0 [39.161] drmOpenDevice: open result is 12, (OK) [39.161] drmOpenByBusid: drmOpenMinor returns 12 [39.161] drmOpenByBusid: Interface 1.4 failed, trying 1.1 [39.161] drmOpenByBusid: drmGetBusid reports pci::01:00.0 [39.296] (EE) AIGLX error: r600 does not export required DRI extension X.Org X Server 1.12.4 -- SY, Marat smime.p7s Description: S/MIME Cryptographic Signature
Re: CFT: CentOS 6.6 base + userland
On Tue, Nov 04, 2014 at 04:14:05PM -0500, Kris Moore wrote: > Does running skype require the lemul branch still, or what minimum > version of FreeBSD? It's a variant of Skype 4.2.0.13 which disguises itself as 4.3.0.37. So, actually, neither (yet). It's been floating around on IRC, mostly. -- Johannes Meixner| FreeBSD Committer x...@freebsd.org| http://people.freebsd.org/~xmj pgpY9GqKC2Hgx.pgp Description: PGP signature
Re: Reducing the size of the ports tree (brainstorm v2)
On Tue, 4 Nov 2014 20:29:44 -0700 (MST) Warren Block wrote > On Tue, 4 Nov 2014, Chris H wrote: > > > On Tue, 4 Nov 2014 16:16:09 -0700 (MST) Warren Block > > wrote > > >> On Tue, 4 Nov 2014, Chris H wrote: > >> > >>> gpart(8) -a gives you what you need. If it's truly as bad as all that, > >>> mounting the ports tree on a 512k aligned slice will reduce the "slack" > >>> you appear to be referring to. zfs(8) also has this ability. > >> > >> Not alignment, but filesystem block size. But that can only be set for > >> an entire filesystem, and it's a tradeoff. > > > > Quite true. Which was meant to be my point. > > Meaning that the ports tree could then be mounted where ever was > > deemed convenient, and wouldn't carry the "slack" it does on a > > 4k boundary. Maybe even on a removable SSD? > > I thought that block suballocation was a thing on most modern > filesystems. There would still be an extra seek or several to locate > the small sub-blocks inside a full block, but it should make space usage > with small files more efficient. But I don't know what either UFS or > ZFS does for that. Difficult to tell for sure. I haven't examined the [UFS/ZFS] source to know for sure. Be valuable info. :) OTOH I only mentioned utilizing a smaller boundary, as I felt it was a reasonable solution related to size issue mentioned. I have just about enough spares laying about, to do some comparison/ benchmarking on UFS v ZFS v 4k v 512b. If I get a chance this week. I'm going to give it a go, and see if I can extrapolate useful data. --Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Reducing the size of the ports tree (brainstorm v2)
On Tue, 4 Nov 2014, Chris H wrote: On Tue, 4 Nov 2014 16:16:09 -0700 (MST) Warren Block wrote On Tue, 4 Nov 2014, Chris H wrote: gpart(8) -a gives you what you need. If it's truly as bad as all that, mounting the ports tree on a 512k aligned slice will reduce the "slack" you appear to be referring to. zfs(8) also has this ability. Not alignment, but filesystem block size. But that can only be set for an entire filesystem, and it's a tradeoff. Quite true. Which was meant to be my point. Meaning that the ports tree could then be mounted where ever was deemed convenient, and wouldn't carry the "slack" it does on a 4k boundary. Maybe even on a removable SSD? I thought that block suballocation was a thing on most modern filesystems. There would still be an extra seek or several to locate the small sub-blocks inside a full block, but it should make space usage with small files more efficient. But I don't know what either UFS or ZFS does for that. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Reducing the size of the ports tree (brainstorm v2)
On Tue, Nov 4, 2014 at 5:39 PM, Matthias Andree wrote: > Am 03.11.2014 um 21:24 schrieb Tijl Coosemans: > > > Other tools won't change anything. It's the file system that would > > have to change which is not going to happen. When the ports tree was > > created disks were much smaller and file systems were better (still not > > good) at storing small files. Today disks are much bigger and file > > systems have adapted to that. Now it's time for the ports tree to adapt. > > So you're saying the only answer we've had to growing storage capacities > was growing block sizes, without adding support for "many small files" > back in. What is this 'support for "many small files"' you are referring to? > That's still the fault of the tool (here: tool == file system) > and not of the ports tree. It's a problem with disk's themselves, not an svn or fs problem. Tail packing is already a part of UFS, and disks for the purposes here basically only read one block at a time. If you have a method of overcoming the inherent seek slowness of reading many small files scattered across the spinning media then please share it so progress can be made. This is definitely a problem with the ports system considering the underlying hw and fs has changed characteristics and ports hasn't accounted for them. -- Adam ___ 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: Reducing the size of the ports tree (brainstorm v2)
On Tue, 4 Nov 2014 16:16:09 -0700 (MST) Warren Block wrote > On Tue, 4 Nov 2014, Chris H wrote: > > > gpart(8) -a gives you what you need. If it's truly as bad as all that, > > mounting the ports tree on a 512k aligned slice will reduce the "slack" > > you appear to be referring to. zfs(8) also has this ability. > > Not alignment, but filesystem block size. But that can only be set for > an entire filesystem, and it's a tradeoff. Quite true. Which was meant to be my point. Meaning that the ports tree could then be mounted where ever was deemed convenient, and wouldn't carry the "slack" it does on a 4k boundary. Maybe even on a removable SSD? --Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Reducing the size of the ports tree (brainstorm v2)
Am 03.11.2014 um 21:24 schrieb Tijl Coosemans: > Other tools won't change anything. It's the file system that would > have to change which is not going to happen. When the ports tree was > created disks were much smaller and file systems were better (still not > good) at storing small files. Today disks are much bigger and file > systems have adapted to that. Now it's time for the ports tree to adapt. So you're saying the only answer we've had to growing storage capacities was growing block sizes, without adding support for "many small files" back in. That's still the fault of the tool (here: tool == file system) and not of the ports tree. ___ 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: Reducing the size of the ports tree (brainstorm v2)
On 11/4/2014 2:28 PM, Chris H wrote: On Tue, 04 Nov 2014 13:21:31 -0800 "Chris H" wrote gpart(8) -a gives you what you need. If it's truly as bad as all that, mounting the ports tree on a 512k aligned slice will reduce the "slack" ahem... that was s/512k/512b/g The issue of 512b sector storage media going underlies this discussion. 4k drives are the new typical. Flash uses even larger block sizes. Using an alignment of less than one sector yields significant performance penalties when doing small reads or writes. The on-disk size of the ports tree more than doubles when using 4k blocks because all those files use 4k to store what often fits in 512b. Cutting down the number of files has wide-reaching performance gains with subversion as well. ___ 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: Reducing the size of the ports tree (brainstorm v2)
On Tue, 4 Nov 2014, Chris H wrote: gpart(8) -a gives you what you need. If it's truly as bad as all that, mounting the ports tree on a 512k aligned slice will reduce the "slack" you appear to be referring to. zfs(8) also has this ability. Not alignment, but filesystem block size. But that can only be set for an entire filesystem, and it's a tradeoff. ___ 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: Reducing the size of the ports tree (brainstorm v2)
On Tue, 04 Nov 2014 13:21:31 -0800 "Chris H" wrote > On Mon, 3 Nov 2014 21:24:38 +0100 Tijl Coosemans wrote > > > On Mon, 03 Nov 2014 09:22:09 +0100 Matthias Andree > > wrote: > Am 31.10.2014 um 19:56 schrieb Baptiste Daroussin: > > >> Hi all, > > >> > > >> tijl@ spotted an interesting point, distinfo and pkg-descr files files > > >> convenient are taking a lot of space for "free", we can reduce the size > > >> of the while ports tree by a factor 2 by simply merging them into one of > > >> the other files (Makefile and/or pkg-plist) from my testing it really > > >> devides significantly the size of the tree. > > >> > > >> Problem is how to merge them if we want to. > > >> > > >> What we do not want to loose: > > >> - Easyness of parsing distinfo > > >> - Easyness to get informations about the description > > >> > > >> so far I have not been able to figure out a user friendly way > > >> > > >> Ideas I got so far only concerns pkg-descr: > > >> Adding an entry in the Makefile for the WWW: > > >> WWW= bla > > >> or an entry in the plist: @www http... > > >> > > >> for the description the Makefile is not suitable as multi line entry in > > >> Makefiles are painful > > >> Maybe a new keyword: > > >> @descr < > >> mydesc > > >> in > > >> multiline > > >> EOD > > >> > > >> which could easily be added to the plist parser in pkg. But I'm do not > > >> find that very friendly in particular for make(1) to extract the data. > > >> > > >> Concerning the distinfo I have no idea. > > >> > > >> so this mail is a call of ideas :), if nothing nice ideas is found we > > >> will just do nothing here :) > > > > > > My urgent recommendation is to leave it as is. Even if it wastes 200 > > > MB. Space is so cheap these days it's not worth introducing new > > > instabilities, re-train all contributors and all that. > > > > > > We haven't even shaken off all the staging and pkg fall-out, and now > > > we're talking about the next revolution. > > > > The numbers on http://beefy1.isc.freebsd.org/ and > > http://beefy2.isc.freebsd.org/ have never been better. > > > > > And if we really decided that we want to change things, we would need > > > these things BEFORE the implementation: > > > > > > 1. a clear list of the problems. > > > 1a. Space does not count, see above. > > > 1b. Insufficient tools (SVN) do not count. If the tools are bad, we > > > need other tools, not change our way of doing things. > > > > Other tools won't change anything. It's the file system that would > > have to change which is not going to happen. > > gpart(8) -a gives you what you need. If it's truly as bad as all that, > mounting the ports tree on a 512k aligned slice will reduce the "slack" ahem... that was s/512k/512b/g :P > you appear to be referring to. zfs(8) also has this ability. > > > When the ports tree was > > created disks were much smaller and file systems were better (still not > > good) at storing small files. Today disks are much bigger and file > > systems have adapted to that. Now it's time for the ports tree to adapt. > > > > Here's another way to look at it. Suppose that distinfo never existed > > and we always specified file sizes and checksums in the Makefile. Then > > someone would come along and suggest to do just that, put file sizes and > > checksums in a separate file named distinfo. Nobody would support that. > > IMHO sorting out all the pkg(8) issues still at large, would be more > prudent use of time, and resources. Just saying. > > --Chris > > > ___ > > freebsd-ports@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > > > ___ > 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" ___ 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: Reducing the size of the ports tree (brainstorm v2)
On Mon, 3 Nov 2014 21:24:38 +0100 Tijl Coosemans wrote > On Mon, 03 Nov 2014 09:22:09 +0100 Matthias Andree > wrote: > Am 31.10.2014 um 19:56 schrieb Baptiste Daroussin: > >> Hi all, > >> > >> tijl@ spotted an interesting point, distinfo and pkg-descr files files > >> convenient are taking a lot of space for "free", we can reduce the size of > >> the while ports tree by a factor 2 by simply merging them into one of the > >> other files (Makefile and/or pkg-plist) from my testing it really devides > >> significantly the size of the tree. > >> > >> Problem is how to merge them if we want to. > >> > >> What we do not want to loose: > >> - Easyness of parsing distinfo > >> - Easyness to get informations about the description > >> > >> so far I have not been able to figure out a user friendly way > >> > >> Ideas I got so far only concerns pkg-descr: > >> Adding an entry in the Makefile for the WWW: > >> WWW= bla > >> or an entry in the plist: @www http... > >> > >> for the description the Makefile is not suitable as multi line entry in > >> Makefiles are painful > >> Maybe a new keyword: > >> @descr < >> mydesc > >> in > >> multiline > >> EOD > >> > >> which could easily be added to the plist parser in pkg. But I'm do not > >> find that very friendly in particular for make(1) to extract the data. > >> > >> Concerning the distinfo I have no idea. > >> > >> so this mail is a call of ideas :), if nothing nice ideas is found we > >> will just do nothing here :) > > > > My urgent recommendation is to leave it as is. Even if it wastes 200 > > MB. Space is so cheap these days it's not worth introducing new > > instabilities, re-train all contributors and all that. > > > > We haven't even shaken off all the staging and pkg fall-out, and now > > we're talking about the next revolution. > > The numbers on http://beefy1.isc.freebsd.org/ and > http://beefy2.isc.freebsd.org/ have never been better. > > > And if we really decided that we want to change things, we would need > > these things BEFORE the implementation: > > > > 1. a clear list of the problems. > > 1a. Space does not count, see above. > > 1b. Insufficient tools (SVN) do not count. If the tools are bad, we > > need other tools, not change our way of doing things. > > Other tools won't change anything. It's the file system that would > have to change which is not going to happen. gpart(8) -a gives you what you need. If it's truly as bad as all that, mounting the ports tree on a 512k aligned slice will reduce the "slack" you appear to be referring to. zfs(8) also has this ability. > When the ports tree was > created disks were much smaller and file systems were better (still not > good) at storing small files. Today disks are much bigger and file > systems have adapted to that. Now it's time for the ports tree to adapt. > > Here's another way to look at it. Suppose that distinfo never existed > and we always specified file sizes and checksums in the Makefile. Then > someone would come along and suggest to do just that, put file sizes and > checksums in a separate file named distinfo. Nobody would support that. IMHO sorting out all the pkg(8) issues still at large, would be more prudent use of time, and resources. Just saying. --Chris > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ 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: CentOS 6.6 base + userland
On 11/04/2014 15:41, Johannes Meixner wrote: > Hello, > > I've spent the last few hours porting CentOS 6.6 to FreeBSD. > > Given RHEL6 (and derived CentOS 6.x) policy of no-surprises, it was pretty > easy > to bump those versions that actually did change. > > I've tested it with poudriere locally, verified that Skype still works ;-), > and would be happy if you could all test away. > > Please check if your favorite games, things like crashplan, matlab, and other > Linux software still works, and notify me if it doesn't for any reason. > > You can find a patch to ports revision 372146 here: > > http://xmj.me/freebsd/centos-6.6.diff > > Best regards, > > -xmj > > Does running skype require the lemul branch still, or what minimum version of FreeBSD? -- Kris Moore PC-BSD Software iXsystems signature.asc Description: OpenPGP digital signature
CFT: CentOS 6.6 base + userland
Hello, I've spent the last few hours porting CentOS 6.6 to FreeBSD. Given RHEL6 (and derived CentOS 6.x) policy of no-surprises, it was pretty easy to bump those versions that actually did change. I've tested it with poudriere locally, verified that Skype still works ;-), and would be happy if you could all test away. Please check if your favorite games, things like crashplan, matlab, and other Linux software still works, and notify me if it doesn't for any reason. You can find a patch to ports revision 372146 here: http://xmj.me/freebsd/centos-6.6.diff Best regards, -xmj -- Johannes Meixner| FreeBSD Committer x...@freebsd.org| http://people.freebsd.org/~xmj pgpHkoBfnnUcj.pgp Description: PGP signature
Re: SSH hangs while restarting services
Hi, On Tue, Nov 04, 2014 at 08:48:03AM +0800, Denny Lin wrote: > > Recently I've been trying to restart services remotely using SSH using a > command instead of entering the shell: > ssh host "sudo service postgresql restart" > > PostgreSQL is able to restart successfully, but SSH just hangs there > instead of exiting. I've noticed that this seems to affect any command > which spawns a child process which doesn't exit. Can you check if it's really ssh which hangs or sudo ? I have just stumbled upon a sudo bug myself: the child process launched by sudo-1.8.11 hangs in the manner you just described. The same command launched by sudo-1.8.10 works fine. Running sudo /bin/sh and quitting the new shell is enough to verify if everything's fine or not. -- Francois Tigeot ___ 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"
