On 10/10/13 01:55 AM, Jonathan Adams wrote:
I'm a user and not a developer, but what you are saying is wrong.
The hipster was set up to be the bleeding edge for developers to work.
Just because you want some new features and have set up your
repositories to include /hipster doesn't mean that i
On 09/10/2013 20:45, Alexander Pyhalov wrote:
...
So, one suggestion is to ship icu library to /usr/g++ (including
icu-config in /usr/g++/bin). I dislike it. :)
The other idea is as we currently don't have internal icu consumers just
to ship it into /usr.
But this is a good idea only if we are
On 10/ 9/13 10:34 AM, Thomas Wagner wrote:
Hi Alexander,
[...]
As always, I'm the one to blame for it. However, this particular conflict
could be caused by directory permission.
True, permissions differ. the pkg contents dump of pkg:/sfe/library/g++/sigcpp
prints what we default to. It s
On 10/09/2013 20:28, Alexander Pyhalov wrote:
I was looking at different php packages.
It seems that currently php-idn upstream is dead.
There are several patches (for example, used in Fedora) which allow it
to be built with php 5.4.
However, some icu functions were moved to intl PHP extension.
On 10/09/2013 18:18, Jonathan Adams wrote:
root@jadlaptop:~# pkg freeze
NAME VERSION DATE
COMMENT
library/g++/sigcpp 2.2.10-0.151.1.5:20120805T144728Z 01 Oct 2013 21:00:41
BST None
library/zlib 1.2.3 18 Sep 2013 16:36:58 BST None
root
So, we have two loosely related issues to discuss.
On 10/09/2013 21:34, Thomas Wagner wrote:
When we can rebuild
everything with GCC, I think it's a good idea to rename libraries to
original names and move back to /usr.
Yes, true for the very limited world of a g++ only Distro. You loose
Hi Alexander,
[...]
> As always, I'm the one to blame for it. However, this particular conflict
> could be caused by directory permission.
True, permissions differ. the pkg contents dump of pkg:/sfe/library/g++/sigcpp
prints what we default to. It should be in sync with what is in /usr.
> W
On 09/22/2013 22:32, Alexander Pyhalov wrote:
Hello.
I've looked at rtorrent/libtorrent and found out that g++ doesn't like
our library/c++/sigcpp (coming from JDS). I suggest that if I rebuild it
with g++, Studio will complain. Any suggestions?
People from opencsw faced this problem and if I un
On 10/09/2013 20:30, ken mays wrote:
Hello,
There was a bug/RFE submitted to review and test the current Net-SNMP 5.4.1
packages in /dev and /hipster.
I noted the library/network package is no longer a dependency, so just wanted
to know if we would respin the Net-SNMP 5.4.1 packages and have i
Hello,
There was a bug/RFE submitted to review and test the current Net-SNMP 5.4.1
packages in /dev and /hipster.
I noted the library/network package is no longer a dependency, so just wanted
to know if we would respin the Net-SNMP 5.4.1 packages and have it 'field'
checked and tested...
~
I was looking at different php packages.
It seems that currently php-idn upstream is dead.
There are several patches (for example, used in Fedora) which allow it
to be built with php 5.4.
However, some icu functions were moved to intl PHP extension. To enable
this extension we need to recompil
On 10/09/2013 18:44, Thomas Wagner wrote:
Hi all,
this is where in SFE package name macros have been invented for.
If a distro starts supplying packages with conflicting files
or even conflicting package names, then in SFE we can parametrize
the package dependencies (called BuildRequires and Req
On 09/10/2013 17:05, Thomas Wagner wrote:
Maybe the problems dicussed here are only a symptom
and *not* the root cause.
No, this discussion came up because some people seem to be
confused about the role of /hipster. This post from Alaisdair
Lumsden clearly described the purpose of /hipster:
Maybe the problems dicussed here are only a symptom
and *not* the root cause.
If you put non-coordinated, non-discussed, non-approved
changes in a consolidation repository to test how things
fit together, then you need not wonder how much and
how bad stuff can break.
The Problem is the missing
Hi all,
this is where in SFE package name macros have been invented for.
If a distro starts supplying packages with conflicting files
or even conflicting package names, then in SFE we can parametrize
the package dependencies (called BuildRequires and Requires in the
spec files).
In this case we w
root@jadlaptop:~# pkg freeze
NAME VERSION DATE
COMMENT
library/g++/sigcpp 2.2.10-0.151.1.5:20120805T144728Z 01 Oct 2013 21:00:41
BST None
library/zlib 1.2.3 18 Sep 2013 16:36:58 BST None
root@jadlaptop:~# pkg info -l library/g++/sigcpp
On 09/10/2013 15:11, Nikola M. wrote:
On 10/ 9/13 02:55 PM, Jonathan Adams wrote:
I'm a user and not a developer, but what you are saying is wrong.
The hipster was set up to be the bleeding edge for developers to work.
No, I think I am still right. Things should be tested before putted in a
p
On 10/ 9/13 02:55 PM, Jonathan Adams wrote:
I'm a user and not a developer, but what you are saying is wrong.
The hipster was set up to be the bleeding edge for developers to work.
No, I think I am still right. Things should be tested before putted in a
public repo.
People can only be pleased
On 10/09/2013 16:55, Jonathan Adams wrote:
You're right that flash videos don't work, and I've had problems with my X
due to the upgrade, until I froze a package, and in fact had to freeze
another (library/g++/sigcpp) because of a conflict with the JDS I have ...
but then again this is the bleed
I'm a user and not a developer, but what you are saying is wrong.
The hipster was set up to be the bleeding edge for developers to work.
Just because you want some new features and have set up your repositories
to include /hipster doesn't mean that it isn't a bleeding edge repository.
You're rig
On 10/ 9/13 01:48 PM, Udo Grabowski (IMK) wrote:
I think that every change to public Hipster repo should be tested before
done.
And it goes for every update or group of them, so it could be tested by
one more or few people, before pushing it public.
How about pushing it to hipster-testing publi
On 09/10/2013 08:55, Nikola M. wrote:
On 10/ 9/13 08:37 AM, Alexander Pyhalov wrote:
On 10/09/2013 10:28, Adam Števko wrote:
Hi,
are there any problematic packages, which don't work with never PHP?
If no, go for it.
I don't know about problematic packages. However, it doesn't mean that
they
On 10/ 9/13 09:05 AM, Alexander Pyhalov wrote:
Hello.
On 10/09/2013 10:55, Nikola M. wrote:
What do you think?
Nikola M.
I think this doesn't work - just not enough users even in /hipster.
Will someone ever use /hipster-testing?
For example. I've just recompiled hpijs. But I personally
On 10/09/2013 12:07, Neddy, NH. Nam wrote:
Related to PHP, how's about Apache and MySQL? Aren't Apache 2.2.24 and
MySQL 5.1 obsolate?
We don't have apache 2.4, so we'll have to preserve apache 2.2.25. As
for MySQL 5.1 - I think it can be dropped when we drop python 2.4.
But firstly we have to
Related to PHP, how's about Apache and MySQL? Aren't Apache 2.2.24 and
MySQL 5.1 obsolate?
On Wed, Oct 9, 2013 at 1:37 PM, Alexander Pyhalov wrote:
> On 10/09/2013 10:28, Adam Števko wrote:
>
>> Hi,
>>
>> are there any problematic packages, which don't work with never PHP? If
>> no, go for it.
Hello.
On 10/09/2013 10:55, Nikola M. wrote:
What do you think?
Nikola M.
I think this doesn't work - just not enough users even in /hipster. Will
someone ever use /hipster-testing?
For example. I've just recompiled hpijs. But I personally don't use it.
How long will it take to find so
26 matches
Mail list logo
