[gentoo-dev] Re: Re: Re: Changes in installed ebuilds

[Jörg Schaible]

Michał Górny wrote:

> Dnia 2014-06-26, o godz. 00:48:02
> Jörg Schaible  napisał(a):
> 
>> hasufell wrote:
>> 
>> > Kristian Fiskerstrand:
>> >> On 06/24/2014 09:25 PM, Jörg Schaible wrote:
>> >>> Alexandre Rostovtsev wrote:
>> >> 
>>  On Mon, 2014-06-23 at 22:15 +0200, Jörg Schaible wrote:
>> > So, why the heck, was the dependency to dev-libs/glib changed
>> > for an existing ebuild without increasing its version (e.g.
>> > dbus-glib-0.100.2-r2)?
>> 
>>  Please see
>>  http://article.gmane.org/gmane.linux.gentoo.devel/91615
>> >> 
>> >>> These blocks had nothing to do with the multilibs ABI. It has been
>> >>> just the updated versions for the dependencies.
>> >> 
>> >> 
>> >> For what it is worth, I completely agree significant changes to stable
>> >> ebuilds (hereunder changes to dependencies) should get a revision bump
>> >> and go through normal stabilization procedures.
>> >> 
>> >> 
>> > 
>> > That would be a waste of time and would increase the overall workload
>> > on arch teams who already need 2-4 weeks to keep up with the queue.
>> > There is no reason to re-stabilize a package after a build-time bug has
>> > been fixed by adjusting the version of a dependency.
>> > 
>> > Moreover, the fix that was applied was very important.
>> 
>> 
>> And, since the official tree did not have an older version of those deps
>> anyway, the upgrade in the stable dependent ebuilds was unnecessary. It
>> just broke the tree for users with local or other overlays.
> 
> But people could have older versions of those deps installed, and then
> their systems would slowly become broken on upgrades. Since the issues
> wouldn't be caught early properly, they would trigger incorrect
> installs of another packages and a few dep-tree branches further,
> an unexpected hard-to-debug failures.

OK, you have a point. However, it is more dependent on the way people use 
emerge. This scenario could not have happen to me, I call emerge always 
with:

   emerge -uDvta --changed-use --with-bdeps=y

Cheers,
Jörg

Re: [gentoo-dev] local repo kernel ebuild search for tar.bz2 instead of tar.xz

[Luis Ressel]

The kernel-2.eclass calls epatch_user, so AFAIK you don't have to
create a local ebuild copy in order to patch the kernel, just drop your
patches in /etc/portage/patches/sys-kernel/hardened-sources/.


Regards,
Luis Ressel


signature.asc
Description: PGP signature

[gentoo-dev] net-analyzer/mausezahn - last rites

[Jeroen Roovers]

profiles/package.mask:

# Jeroen Roovers  (26 Jun 2014)
# Development has halted (see )
# See net-analyzer/netsniff-ng for a replacement (bug #515210)
net-analyzer/mausezahn


 jer

Re: [gentoo-dev] local repo kernel ebuild search for tar.bz2 instead of tar.xz

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 26/06/14 01:46 PM, Mike Pagano wrote:
> On Thu, Jun 26, 2014 at 07:37:40PM +0300, Kfir Lavi wrote:
>> Hi, I have copied ebuild from sys-kernel/hardened-sources to my
>> local repository, in order to patch the sources. I didn't change
>> the ebuild for now, but repoman manifest does not work. It tries
>> to download files with extension tar.bz2 and not tar.xz. If I
>> delete my local copy of the ebuild, emerge will work ok from the 
>> global portage tree. I think bug
>> [1]https://bugs.gentoo.org/show_bug.cgi?id=421721 is related to
>> my problem, as it changed the extension of tar archives from bz2
>> to xz. Maybe there is a global flag I need to specify in order to
>> inherit gentoo main tree behaviour? Regards, Kfir
>> 
>> References
>> 
>> 1. https://bugs.gentoo.org/show_bug.cgi?id=421721
> 
> 
> Check that you are using the latest kernel-2.eclass in your local
> repo.
> 
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/kernel-2.eclass?view=log
>
> 
Diff to previous 1.278
> 
> Revision 1.279 - (view) (download) (annotate) - [select for diffs]
>  Sat Mar 9 21:05:50 2013 UTC (15 months, 2 weeks ago) by tomwij 
> Kernel sources and (gen)patches now use xz instead of bz2. Bug
> #421721
> 
> 


Alternatively, check that you have 'masters = gentoo' in your local
repo's metadata/layout.conf file , that will make it use the eclasses
from the main tree.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlOsZYcACgkQ2ugaI38ACPDiZgD/dc40rYqGryAdxAZrnxMlvq0I
gsu1bNbdMgq9vkmxNcUA/3XKz+UVmL5ecGi8xBSX4iNt5mcf7F7YHrSZytxexRwG
=J/PZ
-END PGP SIGNATURE-

Re: [gentoo-dev] local repo kernel ebuild search for tar.bz2 instead of tar.xz

[Mike Pagano]

On Thu, Jun 26, 2014 at 07:37:40PM +0300, Kfir Lavi wrote:
>Hi,
>I have copied ebuild from sys-kernel/hardened-sources to my local
>repository, in order to patch the sources.
>I didn't change the ebuild for now, but repoman manifest does not work.
>It tries to download files with extension tar.bz2 and not tar.xz.
>If I delete my local copy of the ebuild, emerge will work ok from the
>global portage tree.
>I think bug [1]https://bugs.gentoo.org/show_bug.cgi?id=421721
>is related to my problem, as it changed the extension of tar archives
>from bz2 to xz.
>Maybe there is a global flag I need to specify in order to inherit
>gentoo main tree behaviour?
>Regards,
>Kfir
> 
> References
> 
>1. https://bugs.gentoo.org/show_bug.cgi?id=421721


Check that you are using the latest kernel-2.eclass in your local repo.

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/kernel-2.eclass?view=log
Diff to previous 1.278

Revision 1.279 - (view) (download) (annotate) - [select for diffs] 
Sat Mar 9 21:05:50 2013 UTC (15 months, 2 weeks ago) by tomwij 
Kernel sources and (gen)patches now use xz instead of bz2. Bug #421721


-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead 
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index

[gentoo-dev] local repo kernel ebuild search for tar.bz2 instead of tar.xz

[Kfir Lavi]

Hi,
I have copied ebuild from sys-kernel/hardened-sources to my local
repository, in order to patch the sources.
I didn't change the ebuild for now, but repoman manifest does not work.
It tries to download files with extension tar.bz2 and not tar.xz.
If I delete my local copy of the ebuild, emerge will work ok from the
global portage tree.
I think bug https://bugs.gentoo.org/show_bug.cgi?id=421721
is related to my problem, as it changed the extension of tar archives from
bz2 to xz.

Maybe there is a global flag I need to specify in order to inherit gentoo
main tree behaviour?

Regards,
Kfir

[gentoo-dev] Re: Maintainer request: sys-apps/kmscon

[Alexey Shvetsov]

Matt Turner писал 26-06-2014 09:42:

alexxy added it more than a year ago to the tree as part of the x11
herd, of which he isn't a maintainer. It hasn't been really seen any
attention and is broken with current versions of Mesa. I've pinged him
multiple times to see if he's planning to handle any of the
outstanding bugs.

Someone please take over maintenance and fix up this package?


Seems i forgot to add it to maintainer needed. Also kmscon now too much 
systemd dependent.


--
Best Regards,
Alexey 'Alexxy' Shvetsov, PhD
Department of Molecular and Radiation Biophysics
FSBI Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Leningrad region, Gatchina, Russia
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexx...@gmail.com
mailto:ale...@gentoo.org
mailto:ale...@omrb.pnpi.spb.ru

Re: [gentoo-dev] Re: Re: Changes in installed ebuilds

[Michał Górny]

Dnia 2014-06-26, o godz. 00:48:02
Jörg Schaible  napisał(a):

> hasufell wrote:
> 
> > Kristian Fiskerstrand:
> >> On 06/24/2014 09:25 PM, Jörg Schaible wrote:
> >>> Alexandre Rostovtsev wrote:
> >> 
>  On Mon, 2014-06-23 at 22:15 +0200, Jörg Schaible wrote:
> > So, why the heck, was the dependency to dev-libs/glib changed
> > for an existing ebuild without increasing its version (e.g.
> > dbus-glib-0.100.2-r2)?
> 
>  Please see
>  http://article.gmane.org/gmane.linux.gentoo.devel/91615
> >> 
> >>> These blocks had nothing to do with the multilibs ABI. It has been
> >>> just the updated versions for the dependencies.
> >> 
> >> 
> >> For what it is worth, I completely agree significant changes to stable
> >> ebuilds (hereunder changes to dependencies) should get a revision bump
> >> and go through normal stabilization procedures.
> >> 
> >> 
> > 
> > That would be a waste of time and would increase the overall workload on
> > arch teams who already need 2-4 weeks to keep up with the queue. There
> > is no reason to re-stabilize a package after a build-time bug has been
> > fixed by adjusting the version of a dependency.
> > 
> > Moreover, the fix that was applied was very important.
> 
> 
> And, since the official tree did not have an older version of those deps 
> anyway, the upgrade in the stable dependent ebuilds was unnecessary. It just 
> broke the tree for users with local or other overlays.

But people could have older versions of those deps installed, and then
their systems would slowly become broken on upgrades. Since the issues
wouldn't be caught early properly, they would trigger incorrect
installs of another packages and a few dep-tree branches further,
an unexpected hard-to-debug failures.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature