Kent Fredric kentfred...@gmail.com wrote:
On 27 July 2014 02:12, Martin Vaeth mar...@mvath.de wrote:
Do not forget modification of eclasses which then require mass bumps!
I'm curious what the -r1.1 technique would do here.
I mean, wouldn't that mean you have 2 ebuilds that are identical
hasufell hasuf...@gentoo.org wrote:
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
This looks like a private lesson
*If* there is a corresponding passage in PMS, it seems to be
somewhat hidden (as I pointed out) and certainly many others
haven't found this, either.
(As the eix
On Sun, 27 Jul 2014, Martin Vaeth wrote:
Kent Fredric kentfred...@gmail.com wrote:
-r1.1 weirdness feels like it may cause more problems than it solves.
So far, nobody pointed out any problem which would be caused by -r1.1.
Which is not surprising, since the idea is that -r1.1 cannot be
On 27 July 2014 19:16, Martin Vaeth mar...@mvath.de wrote:
Not at all, it is completely identical to a revision bump:
If you would use -r2 instead of -r1.1, you also would end up
in -r1 and -r2 being identical.
Actually, in both cases, you would *remove* -r1, since -r1 is incorrect
since it
# Pacho Ramos pa...@gentoo.org (27 Jul 2014)
# Upstream dead, fails tests, nothing needs it.
# Removal in a month (#336256)
app-crypt/opencdk
# Pacho Ramos pa...@gentoo.org (27 Jul 2014)
# Upstream dead for ages, fails to build due underlinking,
# nothing needs it (#367573). Removal in a month.
On 26/07/14 15:49, Ciaran McCreesh wrote:
On Sat, 26 Jul 2014 12:41:16 + (UTC)
Martin Vaeth mar...@mvath.de wrote:
hasufell hasuf...@gentoo.org wrote:
Dynamics deps are already broken, not consistently enabled (e.g.
when subslots are in use)
Just to make it clear: No, dynamic deps are
Samuli Suominen:
On 26/07/14 15:49, Ciaran McCreesh wrote:
On Sat, 26 Jul 2014 12:41:16 + (UTC)
Martin Vaeth mar...@mvath.de wrote:
hasufell hasuf...@gentoo.org wrote:
Dynamics deps are already broken, not consistently enabled (e.g.
when subslots are in use)
Just to make it clear: No,
On 7/27/14, 1:42 PM, Samuli Suominen wrote:
Only one person said he had to manually build 2 GNOME related packages,
simple-scan and something else
So, broken? Far from it. More like essential feature.
People have just listed some known races dynamic deps have, and I take
those races
Paweł Hajdan, Jr.:
On 7/27/14, 1:42 PM, Samuli Suominen wrote:
Only one person said he had to manually build 2 GNOME related packages,
simple-scan and something else
So, broken? Far from it. More like essential feature.
People have just listed some known races dynamic deps have, and I take
Am Sonntag, 27. Juli 2014, 13:50:43 schrieb hasufell:
So, broken? Far from it. More like essential feature.
I'm not sure if you realize that you just disabled dynamic deps support
on most of those converted ebuilds.
PLEASE, everyone, don't just make statements like the the one above ^ but
Andreas K. Huettel:
Am Sonntag, 27. Juli 2014, 13:50:43 schrieb hasufell:
So, broken? Far from it. More like essential feature.
I'm not sure if you realize that you just disabled dynamic deps support
on most of those converted ebuilds.
PLEASE, everyone, don't just make statements like
On Sun, Jul 27, 2014 at 6:43 AM, Kent Fredric kentfred...@gmail.com wrote:
In a no dynamic deps, period scenario, this just strikes me as 2 flavours
of the same weirdness, -r2 and -r1.1 are just equally weird choices to make
if the ebuild itself doesn't change at all.
You have a good point
On 27/07/14 14:50, hasufell wrote:
Samuli Suominen:
On 26/07/14 15:49, Ciaran McCreesh wrote:
On Sat, 26 Jul 2014 12:41:16 + (UTC)
Martin Vaeth mar...@mvath.de wrote:
hasufell hasuf...@gentoo.org wrote:
Dynamics deps are already broken, not consistently enabled (e.g.
when subslots are
Am Sonntag, 27. Juli 2014, 14:04:00 schrieb hasufell:
I'm not sure if you realize that you just disabled dynamic deps support
on most of those converted ebuilds.
PLEASE, everyone, don't just make statements like the the one above ^ but
instead explain what has happened and best bring up
On Sun, Jul 27, 2014 at 6:16 AM, Ulrich Mueller u...@gentoo.org wrote:
I wonder if it wouldn't be saner to leave our revision syntax
untouched.
Instead, one could introduce a variable INSTALL_VERSION that would
default to ${PVR} but could be set to the version of a previous ebuild
instead.
Hi all,
your favorite build tool =dev-util/cmake-3.0.0 just hit the tree. If no
regressions show up, we would like to unmask it in ~30 days. Please test it!
Greetings,
--
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD
signature.asc
Description: This is a
Andreas K. Huettel:
Am Sonntag, 27. Juli 2014, 14:04:00 schrieb hasufell:
I'm not sure if you realize that you just disabled dynamic deps support
on most of those converted ebuilds.
PLEASE, everyone, don't just make statements like the the one above ^ but
instead explain what has happened
Samuli Suominen:
On 27/07/14 14:50, hasufell wrote:
Samuli Suominen:
On 26/07/14 15:49, Ciaran McCreesh wrote:
On Sat, 26 Jul 2014 12:41:16 + (UTC)
Martin Vaeth mar...@mvath.de wrote:
hasufell hasuf...@gentoo.org wrote:
Dynamics deps are already broken, not consistently enabled (e.g.
On Sun, Jul 27, 2014 at 8:31 AM, hasufell hasuf...@gentoo.org wrote:
I'm eager to hear how you want to make subslots work with dynamic deps.
:= gets converted to :${SLOT}/${SUBSLOT} in vardb and this is used to
trigger the rebuilds.
How do you record the subslot a package was built against
On Sun, 27 Jul 2014 14:42:24 +0300
Samuli Suominen ssuomi...@gentoo.org wrote:
We just succesfully converted ~300 ebuilds in tree without revision
bumps from virtual/udev[gudev,introspection,static-libs]
to virtual/libudev and virtual/libgudev
Tested it on multiple boxes, went fine.
Testing
Ulrich Mueller:
On Sun, 27 Jul 2014, Martin Vaeth wrote:
Kent Fredric kentfred...@gmail.com wrote:
-r1.1 weirdness feels like it may cause more problems than it solves.
So far, nobody pointed out any problem which would be caused by -r1.1.
Which is not surprising, since the idea is that
Dnia 2014-07-27, o godz. 14:42:24
Samuli Suominen ssuomi...@gentoo.org napisał(a):
On 26/07/14 15:49, Ciaran McCreesh wrote:
On Sat, 26 Jul 2014 12:41:16 + (UTC)
Martin Vaeth mar...@mvath.de wrote:
hasufell hasuf...@gentoo.org wrote:
Dynamics deps are already broken, not
Today some user on IRC noted that there were some doubts about if
developers are allowed to stabilize packages they maintain when they are
able to test on relevant arches (I guess this would benefit amd64 and
x86 mostly as it's likely more spread).
If I don't misremember amd64 team allows that,
Recently I saw some cases where some bugs reported were getting blocked
by some arch teams being slow to reply. The issue is that this pending
bug reports were only related with changes that weren't arch dependent.
Some cases that comes to my mind now:
- Changes only adding systemd unit files
-
On 7/21/14, 11:52 PM, Alexander Berntsen wrote:
Michał has documented the shortcomings of dynamic deps in our wiki[0].
(Thank you!) [...]
[0] https://wiki.gentoo.org/wiki/Project:Portage/Dynamic_dependencies
There's one more thing I'd like to ask about:
For Minor linking change w/ dependency
On Sun, Jul 27, 2014 at 10:05 AM, Paweł Hajdan, Jr.
phajdan...@gentoo.org wrote:
On 7/21/14, 11:52 PM, Alexander Berntsen wrote:
Michał has documented the shortcomings of dynamic deps in our wiki[0].
(Thank you!) [...]
[0] https://wiki.gentoo.org/wiki/Project:Portage/Dynamic_dependencies
Dnia 2014-07-27, o godz. 16:05:34
Paweł Hajdan, Jr. phajdan...@gentoo.org napisał(a):
On 7/21/14, 11:52 PM, Alexander Berntsen wrote:
Michał has documented the shortcomings of dynamic deps in our wiki[0].
(Thank you!) [...]
[0]
On 7/27/14, 4:42 PM, Rich Freeman wrote:
With dynamic deps you'd need to revbump if there is a linking change.
Otherwise portage would just allow the dependency to be removed, and
then linking will break, since the executable is unnecessarily linked
to the dependency (in that scenario).
On Sun, 27 Jul 2014 16:56:17 +0200
Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:
It seems really tricky to correctly reason about dependency
resolution.
It's actually very easy if you do away with all the things that are
making it unnecessarily complicated... Nearly all of the complexity is
On Sun, Jul 27, 2014 at 10:59 AM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Sun, 27 Jul 2014 16:56:17 +0200
Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:
It seems really tricky to correctly reason about dependency
resolution.
It's actually very easy if you do away with all
On Sun, 27 Jul 2014 11:09:05 -0400
Rich Freeman ri...@gentoo.org wrote:
On Sun, Jul 27, 2014 at 10:59 AM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Sun, 27 Jul 2014 16:56:17 +0200
Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:
It seems really tricky to correctly reason about
On Sat, Jul 26, 2014 at 01:45:46PM -0400, Jonathan Callen wrote:
*snip*
If you want to say At most one of the flags 'foo', 'bar', and 'baz'
may be selected, then you say it like so (requires EAPI=5):
REQUIRED_USE=?? ( foo bar baz )
If you want to say Exactly one of the flags ..., then
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/27/2014 09:55 AM, Pacho Ramos wrote:
Today some user on IRC noted that there were some doubts about if
developers are allowed to stabilize packages they maintain when they are
able to test on
On 28 July 2014 02:42, Rich Freeman ri...@gentoo.org wrote:
One thing I would question in that table is applied immediately (but
can break hard when dynamic-deps stop working)). How can dynamically
removing an unused dependency cause something to break, setting
aside bugs in the package
On Sun, Jul 27, 2014 at 11:44 AM, Kent Fredric kentfred...@gmail.com wrote:
On 28 July 2014 02:42, Rich Freeman ri...@gentoo.org wrote:
One thing I would question in that table is applied immediately (but
can break hard when dynamic-deps stop working)). How can dynamically
removing an
On 28 July 2014 03:52, Rich Freeman ri...@gentoo.org wrote:
Why? Is this about removing an unused dependency?
3. Gentoo simply tweaks the ebuild and doesn't bump [A]
What is [A]? What ebuild was tweaked, and how was it tweaked?
Here, A is the derived version of the ebuild of Foo the
Ciaran McCreesh wrote:
Uh huh, so you add an overlay, and suddenly the dependencies for a
random subset of your installed packages change in ways that don't in
any way reflect what you have installed. How is this the desired
behaviour?
There are several different cases of dependency data
As one of the few people working on ARM64 I’m in agreement.
Sure a bug or two is probably going to pop up on account of the change but in
the grand scheme this seems like a good move.
On Jul 27, 2014, at 10:43 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org
wrote:
Signed PGP part
On
El dom, 27-07-2014 a las 07:31 -0700, Matt Turner escribió:
On Sun, Jul 27, 2014 at 7:02 AM, Pacho Ramos pa...@gentoo.org wrote:
Recently I saw some cases where some bugs reported were getting blocked
by some arch teams being slow to reply. The issue is that this pending
bug reports were
Ciaran McCreesh wrote:
Rich Freeman ri...@gentoo.org wrote:
What would you do away with? Being able to virtualize packages
without recompiling everything that depends on them?
Well that's never worked properly or consistently to begin with
Please answer the question?
//Peter
On Sun, 27 Jul 2014 19:02:05 +0200
Peter Stuge pe...@stuge.se wrote:
Ciaran McCreesh wrote:
Rich Freeman ri...@gentoo.org wrote:
What would you do away with? Being able to virtualize packages
without recompiling everything that depends on them?
Well that's never worked properly or
Manuel Rüger wrote:
virtual/libusb-1-r1 depends on either dev-libs/libusb or
sys-freebsd/freebsd-lib. The latter one is only compatible with
libusb-1.0.9,
You should know that it's the other way around. freebsd-lib isn't to
blame, but =dev-libs/libusb-1.0.18 is.
//Peter
pgpDwzxkEwu11.pgp
Ciaran McCreesh wrote:
Peter Stuge pe...@stuge.se wrote:
Ciaran McCreesh wrote:
Rich Freeman ri...@gentoo.org wrote:
What would you do away with? Being able to virtualize packages
without recompiling everything that depends on them?
Well that's never worked properly or
On Sun, 27 Jul 2014 19:16:58 +0200
Peter Stuge pe...@stuge.se wrote:
Ciaran McCreesh wrote:
Peter Stuge pe...@stuge.se wrote:
Ciaran McCreesh wrote:
Rich Freeman ri...@gentoo.org wrote:
What would you do away with? Being able to virtualize
packages without recompiling
On 07/26/2014 08:38 AM, Manuel Rüger wrote:
Hello,
app-admin/chef and its related packages are currently maintainer-needed.
So if you're using chef on Gentoo, this is your chance to step up!
These packages have some restricting dependencies (e.g.
dev-ruby/json-1.7.7), that ruby herd
Dnia 2014-07-27, o godz. 10:42:19
Rich Freeman ri...@gentoo.org napisał(a):
On Sun, Jul 27, 2014 at 10:05 AM, Paweł Hajdan, Jr.
phajdan...@gentoo.org wrote:
On 7/21/14, 11:52 PM, Alexander Berntsen wrote:
Michał has documented the shortcomings of dynamic deps in our wiki[0].
(Thank you!)
The attached patches (attached so that Thunderbird won't mangle them)
fix some of the documentation for multilib-build.eclass, then add a
couple new functions to simplify some use cases where a flag would be
unconditionally enabled for native builds and disabled for non-native
builds.
--
Michał Górny wrote:
Consider the following:
1. A depends on B, both are installed,
2. dependency on B is removed, emerge --depclean uninstalls B thanks
to dynamic-deps,
3. B is treecleaned (nothing depends on it),
So far I follow.
4. old version of A is removed (user doesn't update
On Sun, 27 Jul 2014 22:51:13 +0200
Peter Stuge pe...@stuge.se wrote:
To me it seems like a simple data model bug that vdb does not get
updated to reflect the new situation after step 2 above.
Rewriting VDB won't help if the user doesn't sync at the right time.
--
Ciaran McCreesh
On Sun, Jul 27, 2014 at 4:24 PM, Michał Górny mgo...@gentoo.org wrote:
Dnia 2014-07-27, o godz. 10:42:19
Consider the following:
1. A depends on B, both are installed,
2. dependency on B is removed, emerge --depclean uninstalls B thanks
to dynamic-deps,
3. B is treecleaned (nothing
Dnia 2014-07-27, o godz. 22:51:13
Peter Stuge pe...@stuge.se napisał(a):
What is the purpose of keeping only dependencies as-they-were when
the package was installed, if the package manager does not somehow
benefit from that information in the future?
You have to ask the one who implemented
Dnia 2014-07-27, o godz. 17:08:27
Rich Freeman ri...@gentoo.org napisał(a):
On Sun, Jul 27, 2014 at 4:24 PM, Michał Górny mgo...@gentoo.org wrote:
Dnia 2014-07-27, o godz. 10:42:19
Consider the following:
1. A depends on B, both are installed,
2. dependency on B is removed, emerge
On Sun, Jul 27, 2014 at 5:17 PM, Michał Górny mgo...@gentoo.org wrote:
Dnia 2014-07-27, o godz. 17:08:27
Rich Freeman ri...@gentoo.org napisał(a):
I'd think that portage should update vdb as soon as it detects the
dependency change. Then B would no longer depend on A in vdb. It
shouldn't
On 28 July 2014 08:56, Ciaran McCreesh ciaran.mccre...@googlemail.com
wrote:
To me it seems like a simple data model bug that vdb does not get
updated to reflect the new situation after step 2 above.
Rewriting VDB won't help if the user doesn't sync at the right time.
Indeed. pkgmove has
On Sun, 27 Jul 2014 17:26:27 -0400
Rich Freeman ri...@gentoo.org wrote:
But, in that case you can put the necessary ebuilds into your overlay
and then portage can make everything right.
Oh? Please explain to us a) how the overlay interaction *actually* works
with dynamic dependencies currently,
On Sun, Jul 27, 2014 at 5:27 PM, Kent Fredric kentfred...@gmail.com wrote:
On 28 July 2014 08:56, Ciaran McCreesh ciaran.mccre...@googlemail.com
wrote:
To me it seems like a simple data model bug that vdb does not get
updated to reflect the new situation after step 2 above.
Rewriting VDB
On Sun, Jul 27, 2014 at 5:33 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Sun, 27 Jul 2014 17:26:27 -0400
Rich Freeman ri...@gentoo.org wrote:
But, in that case you can put the necessary ebuilds into your overlay
and then portage can make everything right.
Oh? Please explain
On Sun, Jul 27, 2014 at 8:04 AM, Rich Freeman ri...@gentoo.org wrote:
Doing this would require having portage cache a hash of whatever
ebuild it last parsed, and perhaps its eclasses as well if we permit
revbump-less eclass changes. Then it would have to check for when
these change, perhaps
On 28 July 2014 09:34, Rich Freeman ri...@gentoo.org wrote:
and if it doesn't work for them,
they'll sync in the updates one way or another (using an overlay if
necessary).
However, in the case the package gets removed from tree, an updates based
approach would allow the dependencies to be
On Sun, Jul 27, 2014 at 5:50 PM, Kent Fredric kentfred...@gmail.com wrote:
On 28 July 2014 09:34, Rich Freeman ri...@gentoo.org wrote:
and if it doesn't work for them,
they'll sync in the updates one way or another (using an overlay if
necessary).
However, in the case the package gets
On 28 July 2014 09:46, Rich Freeman ri...@gentoo.org wrote:
Then portage could look for any change in state and that would trigger
a build-less re-merge, which would update vdb with the new state
(including the new hash).
If we're scared about this being worse than what we have, I notice
2014-07-27 23:33 Ciaran McCreesh napisał(a):
On Sun, 27 Jul 2014 17:26:27 -0400
Rich Freeman ri...@gentoo.org wrote:
But, in that case you can put the necessary ebuilds into your overlay
and then portage can make everything right.
Oh? Please explain to us a) how the overlay interaction
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2014-07-27 23h59 UTC.
Removals:
virtual/perl-PodParser 2014-07-21 19:12:16 dilfridge
perl-core/digest-base 2014-07-22 19:34:16 dilfridge
PR == Pacho Ramos pa...@gentoo.org writes:
PR # Pacho Ramos pa...@gentoo.org (27 Jul 2014)
PR # Doesn't build on non-selinux setups (#498032)
PR # Removal in a month.
PR dev-lang/gforth
Did you even try 0.7.3 before coming to that conclusion?
It needs a bump, not a dump.
And for a GNU package
On 27/07/14 08:32 PM, James Cloos wrote:
PR == Pacho Ramos pa...@gentoo.org writes:
PR # Pacho Ramos pa...@gentoo.org (27 Jul 2014)
PR # Doesn't build on non-selinux setups (#498032)
PR # Removal in a month.
PR dev-lang/gforth
Did you even try 0.7.3 before coming to that conclusion?
Kent Fredric kentfred...@gmail.com wrote:
1. User installs Foo
2. Gentoo needs to change what Foo depends on
3. Gentoo simply tweaks the ebuild and doesn't bump [A]
4. User syncs.
5. Subsequent emerges see dependencies from [A] which are fixed and works
in the interim
6. A gets removed.
Michał Górny mgo...@gentoo.org wrote:
Consider the following:
1. A depends on B, both are installed,
2. dependency on B is removed, emerge --depclean uninstalls B thanks
to dynamic-deps,
3. B is treecleaned (nothing depends on it),
4. old version of A is removed (user doesn't update it
Rich Freeman ri...@gentoo.org wrote:
I'd think that a change in repository should probably be treated like
a revbump.
I agree. At least, currently eix already shows [U] in such a situation,
and IMHO it would be wise if portage would suggest to upgrade/downgrade
then, too. But this is a topic
hasufell hasuf...@gentoo.org wrote:
Ulrich Mueller:
I wonder if it wouldn't be saner to leave our revision syntax
untouched.
As already mentioned, -r1.1 is only one of several possible ways
how to achieve the same aim; I am not speaking in favour for a
particular method.
The -r1.1 method has
69 matches
Mail list logo
