Re: mplayer2 for FreeBSD

2012-07-12 Thread Sergey V. Dyatko 
On Thu, 12 Jul 2012 16:16:56 -0400
Jerry  wrote:

> On Thu, 12 Jul 2012 12:00:20 -0500
> Zhihao Yuan articulated:
> 
> > On Thu, Jul 12, 2012 at 7:03 AM, Jerry  wrote:
> > > I was wondering if anyone had actually attempted to compile
> > > mplayer2  on FreeBSD or if there was
> > > someone working on porting it?
> > 
> > I'm using it, and it seems to be a nice replace to mplayer.
> > 
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/163438
> 
> This had not been committed yet though, if I am interpreting it
> correctly.
> 

Yep, but you can test it and submit follow-up like 'it works like a
charm!' , also you can ping miwi@ :)

-- 
wbr, tiger
___
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"

9.0 -Release, xorg, slim, xfce4 Problem logging in.

2012-07-12 Thread cody chandler 
Hello,

FBSD 9 Release I386

  Fresh install I can reproduce and have this issue 5 times now.
Reinstalled the same machine but not sure where the problem is.

Root Logins fine from console and slim.  XFCE4 loads normally.

User Logins fine from console but slim errors..  "Unable to contact
settings server"  "Failed to connect to socket /var/tmp/dbus-##:
Connection refused"  The ## are numbers and letters that changed each
attempt to login with the User.

in /etc/ttys turned slim to off.  at console User is able to load XFCE4
with  /usr/local/bin/startxfce4

per /usr/local/etc/rc.d/slim  I set the ttys file as it recommended.
(ttyv8 /usr/local/bin/slim xterm on secure)

If I use the rc.conf file with (slim_enable="YES")  User can login from
slim without issue.

Only other port installed is Tmux.

The install cd is the same I've used at least 30 times or more for
installing and reinstalling.

I feel I am not doing something correct.  Any direction to help fix this is
welcome.  If I'm missing it.. Please tell me :)

Thanks
Cody
___
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: [HEADSUP & CFT] pkg 1.0rc1 and schedule

2012-07-12 Thread Doug Barton 
On 07/12/2012 03:02 PM, Baptiste Daroussin wrote:
> On Thu, Jul 12, 2012 at 11:48:41AM -0700, Doug Barton wrote:
>> I do not mean this e-mail to be in any way critical. I was told after
>> the new OPTIONS framework discussion that I should have asked questions
>> before the change, so I'm asking these questions now; in a genuine
>> attempt to get information.
>>
>> On 07/12/2012 03:01 AM, Baptiste Daroussin wrote:
>>
>> In the time that you have been working on this project I have asked
>> numerous times for you(pl.) to answer the following questions:
>>
>> 1. What are the goals for pkg?
> 
> The why part of this mail should reply this question, no?

Well clearly not, because if it did I wouldn't keep asking the same
questions over and over again. :)

> Anyway the goal is to have a decent package manager, providing modern 
> features:
> repositories, decent dependency tracking, decent reverse dependency tracking,
> managing upgrade correctly (I'll explain this more later), provide a decent
> library for third party tools (desktop integration via PackageKit for example)

I don't know what "decent" means. I don't know what "modern features"
means (beyond the buzzwords that you've included).

> Providing easy package management for enterprise

Having set up package management systems for enterprises before, *this*
is actually a big-picture goal that I have a lot of sympathy for. But
again, what's missing is *details* about here is what large enterprises
need to make things work for them, here's why the existing tools don't
meet those needs, and here is how pkg does meet them.

> (who never got problems
> managing packages on a large set of freebsd servers, and how complicated it is
> on FreeBSD to have automated reliable puppet,salt,chef,cfengine like tools)
> One of the proof of this problem is how fast people integrated pkgng in those
> tools.

This gets to the heart of my biggest fear regarding this whole project.
It's new, it's shiny, and it looks like forward progress is being made.
Thus, it's attracted a lot of attention, input, time, etc. Heck, it may
even BE forward progress, but I don't know how to measure that because I
don't know what the goals of the project are. Thus, my fear is that
without *details* about what the project is, and what it's trying to
accomplish, we're going to put an exponentially larger volume of work
into the transition and end up no closer to the goal of having a mature
package management system.

And just to be clear, I am *not* saying that "pkg sucks" or that it's
bad, or wrong, or anything else. I'm saying that I don't know how to
evaluate it, because you haven't given us a criteria by which to measure
it.

So what's the problem? We *desperately* need a better system for ports
and packages. We only have so many person-hours we can devote to making
that happen. If we spend all of them on pkg, and it ends up not helping
us enough, we've burnt out our volunteers for no good reason.

>> 2. Why can't the existing tools fulfill those goals?
> 
> The existing tools can't fulfill those goals, because they are hardly
> maintainable, the code hasn't change much since when they were written, lot of
> people have tried over the year to improve them, but all of them gave up. The
> design of the tools, (I mean the code) is really imho not adapted to be
> improved, I spent a lot of time trying to work on it before starting a 
> complete
> new project.

This paragraph really frightens me.

> For example they do not know what is a version, they do not know what are the
> reverse dependencies except through this ugly hack that is +REQUIRED_BY, the
> database is pretty fragile: who never got the package corrupted: empty @pkgdep
> line for example.

So these 2 are a lot closer to what I'd like to see ... *details* about
what isn't working now. I would tend to disagree with you that
+REQUIRED_BY is an ugly hack, it's no uglier than any of the other text
file based dependency tracking we have. But thank you for giving us more
information.

So taking your last example, how does pkg handle the situation where the
user wants to forcibly delete a package that is depended on by another
package?

>> 3. How does pkg fulfill them?
>>
>> You've put some of this in the various places where pkg is documented,
>> but I don't see any thorough treatment of these questions. You have some
>> of it below, which I'd like to see expanded on if you would be so kind. :)
> 
> It is true that, I'm not very good at documenting in general, and even more in
> english, hopefully, the documentation is improving a lot recently, there is 
> the
> for usage:
> http://wiki.freebsd.org/PkgPrimer
> and for all other things:
> http://wiki.freebsd.org/pkgng
> 
> Lot of native english speakers have joined the project and help with
> documentation, if you find someting missing, do not hesitate to had the 
> section
> in the apropriate wiki page, I often have a look at them, and try to fill all
> the blank section to answer user que

Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule

2012-07-12 Thread Michel Talon 
Doug Barton wrote:
> What I'm looking for is compelling motivation to make this overwhelming
> change to the ports infrastructure.
Because the present state of the ports system is not a compelling enough 
reason?  My
arms are falling …



--

Michel Talon
ta...@lpthe.jussieu.fr

Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule

2012-07-12 Thread Baptiste Daroussin 
On Thu, Jul 12, 2012 at 11:48:41AM -0700, Doug Barton wrote:
> I do not mean this e-mail to be in any way critical. I was told after
> the new OPTIONS framework discussion that I should have asked questions
> before the change, so I'm asking these questions now; in a genuine
> attempt to get information.
> 
> On 07/12/2012 03:01 AM, Baptiste Daroussin wrote:
> 
> In the time that you have been working on this project I have asked
> numerous times for you(pl.) to answer the following questions:
> 
> 1. What are the goals for pkg?

The why part of this mail should reply this question, no?

Anyway the goal is to have a decent package manager, providing modern features:
repositories, decent dependency tracking, decent reverse dependency tracking,
managing upgrade correctly (I'll explain this more later), provide a decent
library for third party tools (desktop integration via PackageKit for example)

Providing easy package management for enterprise (who never got problems
managing packages on a large set of freebsd servers, and how complicated it is
on FreeBSD to have automated reliable puppet,salt,chef,cfengine like tools)
One of the proof of this problem is how fast people integrated pkgng in those
tools.

> 2. Why can't the existing tools fulfill those goals?

The existing tools can't fulfill those goals, because they are hardly
maintainable, the code hasn't change much since when they were written, lot of
people have tried over the year to improve them, but all of them gave up. The
design of the tools, (I mean the code) is really imho not adapted to be
improved, I spent a lot of time trying to work on it before starting a complete
new project.

For example they do not know what is a version, they do not know what are the
reverse dependencies except through this ugly hack that is +REQUIRED_BY, the
database is pretty fragile: who never got the package corrupted: empty @pkgdep
line for example.

> 3. How does pkg fulfill them?
> 
> You've put some of this in the various places where pkg is documented,
> but I don't see any thorough treatment of these questions. You have some
> of it below, which I'd like to see expanded on if you would be so kind. :)

It is true that, I'm not very good at documenting in general, and even more in
english, hopefully, the documentation is improving a lot recently, there is the
for usage:
http://wiki.freebsd.org/PkgPrimer
and for all other things:
http://wiki.freebsd.org/pkgng

Lot of native english speakers have joined the project and help with
documentation, if you find someting missing, do not hesitate to had the section
in the apropriate wiki page, I often have a look at them, and try to fill all
the blank section to answer user questions.
> 

> > Why pkg?
> > pkg_* tools have become hardly maintainable over the time,
> 
> I agree on this point, but the right solution (as some of us have been
> saying for years) is to move the pkg_* tools into the ports tree. You
> are correctly handling that by keeping pkg in the ports tree, I'm simply
> pointing out that this isn't a reason we need to switch to pkg.
> 
> > it lacks lots of features most of people are expecting from a package 
> > manager:
> >   - binary upgrade
> 
> I'm not sure what you mean by this. We have the ability to create binary
> packages now.

No we haven't :), I know we can mimic a binary upgrade using for example
portmaster (I describe this in a poudriere howto) but this is not fully binary
upgrade, it is deinstalling/reinstalling a package. Binary upgrade is much more
complexe than that, for example one thing you can't handle now is a package that
has been splitted into lib vs runtime will break with the current way we can do
it. Just as an example.

Just have a look at this old video:
http://www.youtube.com/watch?v=iBgcuKF8R_A (it is only 1m30)

> 
> >   - ability to search information about remote packages
> 
> This is a good feature, certainly. However there is no reason we can't
> create a tool to do this, or add the functionality to an existing tool.

Have a look at what pkgng can present you as information and you will see the
difference.

> 
> >   - real reverse dependency tracking
> >   - tracking leaves
> 
> Can you expand on what these 2 mean?

Of course. The current reverse dependency tracking in pkg_install is a hack: a
+REQUIRED_BY file trying to maintain the list of packages that may depend on the
said dependency, a good way to see it is a hack is to see how often the file get
broken (and on portmaster you added an options to fix them so you might know :))

> 
> What I'm looking for is compelling motivation to make this overwhelming
> change to the ports infrastructure.

There is not much changes needed in the ports infrastructure. It now works ootb
But there are tons of improvements pkgng will offers, like: ability to simply
add new plist keyword without the need of modifying pkgng, native support for
registering a package from a stagedir.
> 
> 
> > Schedule
> > 
> > 
> > The plan is to s

Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule

2012-07-12 Thread Doug Barton 
On 07/12/2012 02:11 PM, Craig Rodrigues wrote:
> You might want to view Baptiste's pkgng presentation at BSDCan:
> 
> http://www.youtube.com/watch?v=4Hxq7AHZ27I

Sure, the next time I have an hour to spare.

I don't think what I'm asking for is unreasonable. One could even
conclude that answering those 3 questions should have been a
prerequisite for starting down this road in the first place.

Doug
___
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: [HEADSUP & CFT] pkg 1.0rc1 and schedule

2012-07-12 Thread Craig Rodrigues 
On Thu, Jul 12, 2012 at 11:48 AM, Doug Barton  wrote:

> 1. What are the goals for pkg?
> 2. Why can't the existing tools fulfill those goals?
> 3. How does pkg fulfill them?
>
>
Hi,

You might want to view Baptiste's pkgng presentation at BSDCan:

http://www.youtube.com/watch?v=4Hxq7AHZ27I

For me, that presentation clarified the goals and motivation
of the pkgng project.

After viewing that presentation, for me it put into perspective some of the
other pkgng information at http://wiki.freebsd.org/pkgng/ .

-- 
Craig Rodrigues
rodr...@crodrigues.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: mplayer2 for FreeBSD

2012-07-12 Thread Jerry 
On Thu, 12 Jul 2012 12:00:20 -0500
Zhihao Yuan articulated:

> On Thu, Jul 12, 2012 at 7:03 AM, Jerry  wrote:
> > I was wondering if anyone had actually attempted to compile mplayer2
> >  on FreeBSD or if there was someone
> > working on porting it?
> 
> I'm using it, and it seems to be a nice replace to mplayer.
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/163438

This had not been committed yet though, if I am interpreting it
correctly.

-- 
Jerry ♔

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
__

___
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 ORDER

2012-07-12 Thread Lewis Investment 
Good day 

How are you and business?  

We also want to know the quantity that can contain 1x40ft container and also 
how many cartons can you load in 1x40ft.  
Please tell us means of payment and how many days it will take you to produce 
after part payment (remit) is made to your account. 
Please click this link below to view the sample of the products we want and 
also comment to us if your company can produce same product, this will enable 
us know how much quantity list we want. 

http://www.ip21.cl/css/657/index.htm

We would love to give your company a brand name to label on our goods. 

We need your urgent respond. 

While thanking you for anticipation and future business ahead 

Best regards.
Lewis Culler


___
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: [HEADSUP & CFT] pkg 1.0rc1 and schedule

2012-07-12 Thread Doug Barton 
I do not mean this e-mail to be in any way critical. I was told after
the new OPTIONS framework discussion that I should have asked questions
before the change, so I'm asking these questions now; in a genuine
attempt to get information.

On 07/12/2012 03:01 AM, Baptiste Daroussin wrote:

In the time that you have been working on this project I have asked
numerous times for you(pl.) to answer the following questions:

1. What are the goals for pkg?
2. Why can't the existing tools fulfill those goals?
3. How does pkg fulfill them?

You've put some of this in the various places where pkg is documented,
but I don't see any thorough treatment of these questions. You have some
of it below, which I'd like to see expanded on if you would be so kind. :)

> Why pkg?
> 
> pkg_* tools have become hardly maintainable over the time,

I agree on this point, but the right solution (as some of us have been
saying for years) is to move the pkg_* tools into the ports tree. You
are correctly handling that by keeping pkg in the ports tree, I'm simply
pointing out that this isn't a reason we need to switch to pkg.

> it lacks lots of features most of people are expecting from a package manager:
>   - binary upgrade

I'm not sure what you mean by this. We have the ability to create binary
packages now.

>   - ability to search information about remote packages

This is a good feature, certainly. However there is no reason we can't
create a tool to do this, or add the functionality to an existing tool.

>   - real reverse dependency tracking
>   - tracking leaves

Can you expand on what these 2 mean?

What I'm looking for is compelling motivation to make this overwhelming
change to the ports infrastructure.


> Schedule
> 
> 
> The plan is to switch the ports tree to pkgng on CURRENT by default on July 
> 25th
> No dates are planned yet for other branches.

Can you describe how this is going to be done? I assume with an
OSVERSION knob in bsd.port.mk?

> Note that there will be a NO_PKGNG knob for some time (undefined yet) for 
> people
> not will to switch on July 25th
> 
> Please also note that some ports won't work with pkgng right now, because 
> pkgng
> is more strict than pkg_install on purpose.
> The major one is: nvidia drivers, because pkgng does not allow to overwrite a 
> file
> owned by another package, and we will not accept any hacks for that in pkgng.

IMO it would be a very large mistake to switch the default in any branch
until the problem with the nvidia drivers is sorted out. We have a lot
of users (myself included) who use this port, and by switching the
default there's going to be 1 of 2 outcomes for those users. Either they
will opt-out, which means you won't get the level of testing you're
looking for; or you'll break their existing ports installation. Neither
outcome is desirable.

Doug
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: mplayer2 for FreeBSD

2012-07-12 Thread Zhihao Yuan 
On Thu, Jul 12, 2012 at 7:03 AM, Jerry  wrote:
> I was wondering if anyone had actually attempted to compile mplayer2
>  on FreeBSD or if there was someone working
> on porting it?

I'm using it, and it seems to be a nice replace to mplayer.

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/163438

>
> --
> Jerry ♔
>
> Disclaimer: off-list followups get on-list replies or get ignored.
> Please do not ignore the Reply-To header.
> __
>
> We live in a world where losing your phone is more dramatic to a
> sixteen year old girl than losing her virginity.
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"



-- 
Zhihao Yuan, nickname lichray
The best way to predict the future is to invent it.
___
4BSD -- http://4bsd.biz/
___
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: [HEADSUP & CFT] pkg 1.0rc1 and schedule

2012-07-12 Thread Marin Atanasov Nikolov 
On Thu, Jul 12, 2012 at 1:01 PM, Baptiste Daroussin  wrote:

> Tools being worked on (or I heard people are interested) :
>   - salt support (in version 0.10) 
> http://salt.readthedocs.org/en/v0.10.0/ref/modules/all/salt.modules.freebsdpkg.html
>   - cfengine support

And here's a link to the Cfengine 3 + pkgng documentation :)

 - http://unix-heaven.org/cfengine3-freebsd-pkgng

Regards,
Marin



-- 
Marin Atanasov Nikolov

dnaeon AT gmail DOT com
daemon AT unix-heaven DOT org
http://www.unix-heaven.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"

mplayer2 for FreeBSD

2012-07-12 Thread Jerry 
I was wondering if anyone had actually attempted to compile mplayer2
 on FreeBSD or if there was someone working
on porting it?

-- 
Jerry ♔

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
__

We live in a world where losing your phone is more dramatic to a
sixteen year old girl than losing her virginity.
___
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: [HEADSUP & CFT] pkg 1.0rc1 and schedule

2012-07-12 Thread Alberto Villa 
On Thu, Jul 12, 2012 at 12:01 PM, Baptiste Daroussin  wrote:
> Third party tools
> -
>
> Tools supporting natively pkgng
>   - ports-mgmt/portupgrade-devel (soon the main portupgrade will support)
>   - ports-mgmt/pkg_cutleaves
>   - ports-mgmt/poudriere
>   - ports-mgmt/portdowngrade
>   - ports-mgmt/tinderbox-devel (support can be improved)

Also:
- ports-mgmt/portbuilder.
-- 
Alberto Villa, FreeBSD committer 
http://people.FreeBSD.org/~avilla
___
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"

[HEADSUP & CFT] pkg 1.0rc1 and schedule

2012-07-12 Thread Baptiste Daroussin 
Hi,

On behalf of the pkgng team I'm really pleased to announce pkg 1.0 RC1 (aka 
pkgng)

Only bug fixes will be accepted in the RC phase.

What is pkg
---
pkg is a new package manager for FreeBSD. It is designed as a replacement for
the pkg_* tools, and as a full featured binary package manager.

It provides a library that does all the work, and a frontend to be used by users

The ports tree is already able to transparently switch to pkgng by default by
adding WITH_PKGNG=yes to your make.conf

It provides a pkg2ng tool to help converting from an old installation to a new
one.

Test repositories are available on http://pkgbeta.freebsd.org/ (I try to update
them as fast as I can)

It will live forever in the ports tree (with a binary bootstrap in 9 and 10)

Why pkg?

pkg_* tools have become hardly maintainable over the time, it lacks lots of
features most of people are expecting from a package manager:
  - binary upgrade
  - ability to search information about remote packages
  - real reverse dependency tracking
  - tracking leaves
  - many more.

Third party tools
-

Tools supporting natively pkgng
  - ports-mgmt/portupgrade-devel (soon the main portupgrade will support)
  - ports-mgmt/pkg_cutleaves
  - ports-mgmt/poudriere
  - ports-mgmt/portdowngrade
  - ports-mgmt/tinderbox-devel (support can be improved)

Tools supporting pkgng via a patch (I hope it will be reviewed/integrated soon)
  - ports-mgmt/portmaster 
(https://github.com/pkgng/pkgng/blob/master/ports/patch-portmaster-pkgng)

Tools being worked on (or I heard people are interested) :
  - salt support (in version 0.10) 
http://salt.readthedocs.org/en/v0.10.0/ref/modules/all/salt.modules.freebsdpkg.html
  - cfengine support
  - puppet support: (https://github.com/xaque208/puppet-pkgng)
  - ruby bindings: (https://github.com/baloo/libpkg-ruby/)
  - PackageKit

Links
-
  - http://wiki.freebsd.org/PkgPrimer
  - http://wiki.freebsd.org/pkgng

Please report bugs in the github issue tracker:
  - http://github.com/pkgng/pkgng

Schedule


The plan is to switch the ports tree to pkgng on CURRENT by default on July 25th
No dates are planned yet for other branches.

Note that there will be a NO_PKGNG knob for some time (undefined yet) for people
not will to switch on July 25th

Please also note that some ports won't work with pkgng right now, because pkgng
is more strict than pkg_install on purpose.
The major one is: nvidia drivers, because pkgng does not allow to overwrite a 
file
owned by another package, and we will not accept any hacks for that in pkgng.

Road to next version


The road to the next version is already open and lots of work will happen, list
of ideas:
  - remote repositories will be able to display update messages
  - optionnal remote files repository to be able to search which packages to
install if you want a known binary
  - real solver,
  - better support for multi repository
  - provides/requires support
  - stabilisation of the library API
  - reduce as much as possible scripting in packages to allow cross installation
  - many more :D

regards,
Bapt


pgp0rJfXmexvX.pgp
Description: PGP signature