Re: [gentoo-dev] [PATCH v4 00/19] User/group packages
Hi!
Its a good thing that you're reviewing user class. I write some thought
previosly about it.
Why not create some set for standart uid:gid for services so they will
be identicall in all installations?
like slurm has uid:gid 500:500
nginx 80:80 or something...
Michał Górny писал 11-06-2019 19:23:
Hi,
Here's hopefully the final iteration of the patches. Changes since v3:
- changed description to 'System user/group' (from 'service'),
- fixed acct-user to fail when ACCT_USER_GROUPS is empty (and not just
when it is unset).
Please review.
--
Best regards,
Michał Górny
Michał Górny (19):
user.eclass: Remove dead/broken Darwin support
user.eclass: NetBSD has 'getent'
user.eclass: Do not create user-group automatically
user.eclass: Prevent automated home creation in useradd
user.eclass: Support disabling home directory creation
user.eclass: Support forcing specified UID/GID
user.eclass: Die if no free UID/GID is found
user.eclass: Factor out finding nologin into separate function
user.eclass: Introduce esetshell
user.eclass: Introduce eget{user,group}name
user.eclass: Also permit using functions in pkg_*rm phases
user.eclass: Support getting & setting comment field
user.eclass: Introduce e{get,set}groups
acct-group.eclass: A new eclass to maintain group accounts
acct-user.eclass: A new eclass to maintain user accounts
acct-user.eclass: Supporting locking & unlocking accounts
acct-group/ftp: Add 'ftp' group (GID 21)
acct-user/ftp: Add 'ftp' user (UID 21)
net-ftp/ftpbase: Utilize {group,user}/ftp
acct-group/ftp/ftp-0.ebuild| 9 +
acct-group/ftp/metadata.xml| 5 +
acct-user/ftp/ftp-0.ebuild | 14 +
acct-user/ftp/metadata.xml | 5 +
eclass/acct-group.eclass | 124
eclass/acct-user.eclass| 373
eclass/user.eclass | 385 -
net-ftp/ftpbase/ftpbase-0.01-r3.ebuild | 39 +++
profiles/categories| 2 +
9 files changed, 886 insertions(+), 70 deletions(-)
create mode 100644 acct-group/ftp/ftp-0.ebuild
create mode 100644 acct-group/ftp/metadata.xml
create mode 100644 acct-user/ftp/ftp-0.ebuild
create mode 100644 acct-user/ftp/metadata.xml
create mode 100644 eclass/acct-group.eclass
create mode 100644 eclass/acct-user.eclass
create mode 100644 net-ftp/ftpbase/ftpbase-0.01-r3.ebuild
--
Best Regards,
Alexey 'Alexxy' Shvetsov
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: Infiniband/OmniPath/iWARP and other RDMA related staff
В письме от среда, 29 июня 2016 г. 13:19:06 MSK пользователь Holger Hoffstätte написал: > On Wed, 29 Jun 2016 10:07:07 +0300, Alexey Shvetsov wrote: > > Hi all! > > > > I'm going to revive RDMA fabric related things in gentoo. And since its > > not > > Yay! > > > only about infiniband staff but about more generic fabric types there is > > and idea to rename category sys-infiniband to more generic name. > > Suggestions are > > > > sys-rdma > > sys-fabric > > > > What will be inside? It will be RDMA related stuff like OFED, fabric > > userspace drivers (verbs, psm, psm2, libfabric and others), plugins for > > specific devices, tools to flash RDMA cards and other related staff. > > This makes me happy. I've been playing with a standalone libfabric in my > overlay via the sockets/UDP providers, and had nothing but problems when I > tried to add USE flags for the various OFED bits (psm2 etc.) Thats is the part of plan =) > > An up-to-date libfabric that pulls in ofed only when needed would finally > enable people without the otherwise necessary fabric HW to write against > the much more usable & sane (when compared to raw IB verbs) libfabric APIs. > > As far as the name is concerned IMHO fabric sounds less RDMA-specific; > I think the OFI WG now also prefers implementation-neutral terms. In current state i also preffer to rename it to sys-fabric and put all interconnect related stuff here (yes sys-cluster/knem and sys- cluster/open-mx also should go here) So if there will be no objections i will do move in next 2 days > > cheers, > Holger -- Best Regards, Alexey 'Alexxy' Shvetsov, PhD Department of Molecular and Radiation Biophysics FSBI Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Leningrad region, Gatchina, Russia mailto:alexx...@gmail.com mailto:ale...@omrb.pnpi.spb.ru mailto:ale...@gentoo.org signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Infiniband/OmniPath/iWARP and other RDMA related staff
Hi all! I'm going to revive RDMA fabric related things in gentoo. And since its not only about infiniband staff but about more generic fabric types there is and idea to rename category sys-infiniband to more generic name. Suggestions are sys-rdma sys-fabric What will be inside? It will be RDMA related stuff like OFED, fabric userspace drivers (verbs, psm, psm2, libfabric and others), plugins for specific devices, tools to flash RDMA cards and other related staff. -- Best Regards, Alexey 'Alexxy' Shvetsov, PhD Department of Molecular and Radiation Biophysics FSBI Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Leningrad region, Gatchina, Russia mailto:alexx...@gmail.com mailto:ale...@omrb.pnpi.spb.ru mailto:ale...@gentoo.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages up for grab
There also another package that i dont use anymore sci-chemistry/icm Alexey Shvetsov писал 31-03-2016 14:17: There is list of packages that i dont realy use / or dont have hw to test lio-target stack dev-python/configshell dev-python/rtslib sys-block/rtsadmin sys-block/targetcli packages related to qualcom cell modem net-libs/libmbim net-libs/libqmi and sys-apps/gptfdisk -- Best Regards, Alexey 'Alexxy' Shvetsov 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
[gentoo-dev] Packages up for grab
There is list of packages that i dont realy use / or dont have hw to test lio-target stack dev-python/configshell dev-python/rtslib sys-block/rtsadmin sys-block/targetcli packages related to qualcom cell modem net-libs/libmbim net-libs/libqmi and sys-apps/gptfdisk -- Best Regards, Alexey 'Alexxy' Shvetsov 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
[gentoo-dev] Determenistic system group and user id
Hi all!
We trying to use ldap for users @work, many of our workstations running
binary gentoo based distro called Calculate linux. However if we wanna
have wide use of ldap there is a need for determenistic system group
gids names and user uids.
Many ebuilds in tree uses enewgroup and enewuser with -1 (aka next
available parameter)[1]. However it will be much better to set distro
wide deterministic uid and gid for system service name. So for example
ldap users may have determenistic groups like video, audio, plugdev,
etc..
[1] $ egrep '(enewgroup|enewuser)' * -R | awk -F '/' '{print $1 "/" $2}'
| grep -v eclass | sort -u | wc -l
443
So there not so much gid uids needed
--
Best Regards,
Alexey 'Alexxy' Shvetsov
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] Use GLEP27!
Hi! Ok. Since there is GLEP27 we should make it reality. To do so i think we should 1. Have some list of system uid/gid (on wiki for example). Also we need to agree on uid/gid numbers for services 2. Add uid/gid from list to existing ebuilds 3. Make a repoman (or may be eclass) check, that will no allow to commit ebuilds with enewuser enewgroup calls with undefined uids 4. Make some script or howto to migrate to determenistic uids/gids from 1 Robin H. Johnson писал 13-12-2015 23:41: On Sun, Dec 13, 2015 at 09:03:51PM +0300, Alexey Shvetsov wrote: Hi all! We trying to use ldap for users @work, many of our workstations running binary gentoo based distro called Calculate linux. However if we wanna have wide use of ldap there is a need for determenistic system group gids names and user uids. Many ebuilds in tree uses enewgroup and enewuser with -1 (aka next available parameter)[1]. However it will be much better to set distro wide deterministic uid and gid for system service name. So for example ldap users may have determenistic groups like video, audio, plugdev, etc.. GLEP27 was approved for this, however it is barely used. Convert the rest of the tree to use it, and then you'll be done, aside from the existing mess on user systems. -- Best Regards, Alexey 'Alexxy' Shvetsov 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] Determenistic system group and user id
Hi Alec!
Alec Warner писал 14-12-2015 01:23:
On Sun, Dec 13, 2015 at 10:03 AM, Alexey Shvetsov <ale...@gentoo.org>
wrote:
Hi all!
We trying to use ldap for users @work, many of our workstations
running binary gentoo based distro called Calculate linux. However
if we wanna have wide use of ldap there is a need for determenistic
system group gids names and user uids.
Many ebuilds in tree uses enewgroup and enewuser with -1 (aka next
available parameter)[1]. However it will be much better to set
distro wide deterministic uid and gid for system service name. So
for example ldap users may have determenistic groups like video,
audio, plugdev, etc..
So the first question I normally ask here is:
1) Why do you need deterministic uid / gid's?
for exmaple plugdev group may have random gid from range 10-1000+ (i
have some systems when it have gid >1000)
so if you're ldap user want to mount external drive on workstation you
dont know what gid it should have..
2) If you do need deterministic uid / gid's, I would recommend storing
them all in the same place.
For example, you typically want a deterministic UID for a user. To
accomplish this, you add that user to LDAP, give them a UID in LDAP,
and then either add LDAP to nssswitch or use something like nsscache
to sync the ldap UID's into the local system.
3) If you need deterministic GID's I would recommend storing them all
in LDAP and syncing the group memberships locally.
Syncing groups localy is major design error if you have more then 10+
systems.
I never understood why people would think the distro should handle
unique gid / uids. Plus you usually end up running:
1) More than one distro.
Its not the case. Most time there only one 'supported' distro by local
IT stuff.
2) More than one 'flavor' of a single distro where for whatever
reason, uid and gid decisions differed (they renumbered, etc.)
So if you want a consistent GID for a group, store the group name and
gid in ldap and sync it; do not rely on your distro to do it. IMHO
doing so is a design error.
-A
[1] $ egrep '(enewgroup|enewuser)' * -R | awk -F '/' '{print $1 "/"
$2}' | grep -v eclass | sort -u | wc -l
443
So there not so much gid uids needed
--
Best Regards,
Alexey 'Alexxy' Shvetsov
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
--
Best Regards,
Alexey 'Alexxy' Shvetsov
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] Git Migration: go-live!
Hi all! Current repoman complains about headers in ebuilds Creating Manifest for /home/alexxy/Gentoo/gentoo/sys-cluster/open-mx ebuild.badheader 1 sys-cluster/open-mx/open-mx-1.5.4.ebuild: Malformed CVS Header on line: 3 So may be its better to drop $Id: $ completely? Robin H. Johnson писал 09-08-2015 08:36: On Sat, Aug 08, 2015 at 05:47:14PM +, Robin H. Johnson wrote: On Thu, Jul 02, 2015 at 09:39:52PM +, Robin H. Johnson wrote: 2015/08/08 15:00 UTC - Freeze 2015/08/08 19:00 UTC - Git commits open for developers This is going live in a few minutes. There was a lot of delays and snags that were hit. QA has a lot of reviewing to do of in-tree patches with long-standing CVS keyword damage. gkeys is also not sufficiently baked, so we're using some scripting for now instead [1]. The new setup DOES enforce that commits AND pushes are signed. I'm only 90% sure that everything works, but I've spent almost the entire day on it, and there's more to go tomorrow. Other old CVS repos are still closed for the moment, they will re-open tomorrow. 2015/08/09 01:00 UTC - Rsync live again (with lagged changelog) 2015/08/11 - History repo available to graft 2015/08/12 - rsync mirrors carry up-to-date changelogs again These parts are still pending. Quick instructions: Set PORTAGE_GPG_KEY=0xLONG-GPG-KEY in your make.conf $ git config user.signingkey 0xLONG-GPG-KEY $ git clone git+ssh://g...@git.gentoo.org/repo/gentoo.git $ vim ... $ repoman commit -m '...' [2] $ git push --signed (some time later, when you have local unpushed commits you want to rebase instead of merging) $ git pull --rebase -S $ vim ... $ repoman commit -m '...' $ git push --signed (some time later, when you have a local branch you want to merge) $ git merge -S some-branch $ git push --signed [1] The keys as they are in LDAP right now have been used. If you need to change your key, please ping infra as well, so I can update the temporary setup. $ ldapsearch 'gentooStatus=active' gpgfingerprint -Z -LLL \ |grep gpgfingerprint |cut -d: -f2- |tr -d ' ' \ |grep -v 'undefined' | xargs gpg --recv [2] If you commit directly with git commit you MUST pass -S (and ideally -s). -- Best Regards, Alexey 'Alexxy' Shvetsov 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-scm] Re: [gentoo-dev] Git Migration: go-live!
Mike Frysinger писал 09-08-2015 15:43: On 09 Aug 2015 14:54, Alexey Shvetsov wrote: Hi all! please don't top post Current repoman complains about headers in ebuilds Creating Manifest for /home/alexxy/Gentoo/gentoo/sys-cluster/open-mx ebuild.badheader 1 sys-cluster/open-mx/open-mx-1.5.4.ebuild: Malformed CVS Header on line: 3 So may be its better to drop $Id: $ completely? it should look like: # $Id$ but even then, yes, we should just trim the line -mike Since repoman do comparison with header.txt which contains alexxy@x240 ~/Gentoo/gentoo $ cat header.txt # Copyright 1999-2015 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ So we can change last line to $Id$ or since it dont actualy needed we can simply drop it. -- Best Regards, Alexey 'Alexxy' Shvetsov 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
[gentoo-dev] Re: Herd/project cleanup
Hi! However I'm quite inactive now due to local reason, I wanna to stay part of gentoo-kde project =) Johannes Huber писал 27-06-2015 22:39: Hello Kentoos, i think this topic is overdue. Compared to the list of members and real activity i would love to cleanup the herd/project. So please raise your hands to say yes i want to stay part of it or no i am not interested anymore. Please answer me within 90 days. If you reading this mail after the 90 days and be removed, feel free to re-join. Greetings, -- Best Regards, Alexey 'Alexxy' Shvetsov 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] A question to Russian Gentoo Developers Community about import software substitution
Hi! I'm also interested in this. Actualy some years ago we did such atempt localy but it failed. Dmitry Yu Okunev писал 08-05-2015 22:35: Hello. I'm not a Gentoo Developer and sorry if I shouldn't write such messages here. If it's really so then I'll consider this in the future and it will not happen again. The question is only for Russian Gentoo Developers subcommunity. I had been trying to push the idea of creating an united FOSS community to solve problems of the higher school of the Russian Federation. But such initiatives faded due to absence of support of top executives… And now (according to e.g. [1]) it won't be a problem, IMHO. And I'd prefer make a distribution for the higher shool based on Gentoo Linux. So here's the Question: Does anybody interested in creating a consortium to send an application to the Ministry of Communications? [1] http://www.opennet.ru/opennews/art.shtml?num=42189 Best regards, Dmirty. -- Best Regards, Alexey 'Alexxy' Shvetsov 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
[gentoo-dev] Re: Maintainer request: sys-apps/kmscon
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: The state and future of the OpenRC project
В письме от 9 июня 2014 01:36:49 пользователь Michael Palimaka написал: On 06/09/2014 12:41 AM, hasufell wrote: The amount of contributors (with real patches and real ebuilds) is constantly decreasing, because our workflow is horrible. I hope you don't actually think that bugzilla is an appropriate review platform. The problem is finding improvements that everyone is happy with. Gerrit is a no-go as Infra has expressed previously they do not want to touch Java. I set up a public Review Board instance against gentoo-x86 a while back but that saw zero instance. In the KDE and Qt teams we've seen much improved rates of user contribution since maintaining a mirror on GitHub, but excessive use may cause a problem in relation to our social contract (and many people just plain don't like GitHub). Perhaps we could consider GitLab? Yep. Its better to have gitlab || gerrit || ReviewBoard Personaly i have only expirience with gerrit However this will depend on migration of gentoo-x86 to git -- Best Regards, Alexey 'Alexxy' Shvetsov, PhD Department of Molecular and Radiation Biophysics FSBI Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Leningrad region, Gatchina, Russia mailto:alexx...@gmail.com mailto:ale...@omrb.pnpi.spb.ru mailto:ale...@gentoo.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
Michał Górny писал 27-05-2014 09:34: Dnia 2014-05-26, o godz. 23:15:34 Samuli Suominen ssuomi...@gentoo.org napisał(a): UPower upstream removed sys-power/pm-utils support from 0.99 release (currently unkeyworded in tree), as in, from current git master. Don't worry. Looking at the past, I can guess this is only a temporary inconvenience. I'm pretty sure upower will be discontinued soon and replaced with systemd-powerd or something :D. So again there will be mad bycicle on scrappers called systemd =\ -- Best Regards, Alexey 'Alexxy' Shvetsov 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
[gentoo-dev] Packages up for grabs
Hi all! There are a list of packages up for grabs. I cannnot test anymore some of them, or i stopped use them. app-text/fbreader dev-libs/liblinebreak net-wireless/madwimax net-wireless/wimax-tools net-wireless/wimax net-wireless/wpa_supplicant sys-fs/ocfs2-tools www-apps/owncloud www-apps/rutorrent -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Developer mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Review Board for Gentoo
Yep I'm thinking about gerrit like workflow. But seems it doesnt make sense with RB and CVS. В письме от 29 мая 2013 10:22:29 пользователь Tomáš Chvátal написал: He is probably thinking about buildtests and automatic commit merges which are not possible with reviewboard. Dne 29.5.2013 9:09 Michael Palimaka kensing...@gentoo.org napsal(a): On 29/05/2013 02:07, Alexey Shvetsov wrote: Hi! Cool! I didnt use RB before, but i use gerrit. Do you pan to integrate it to g.o.g.o? It seems can be done by git commit hooks What sort of integration did you have in mind? -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Review Board for Gentoo
Hi! Cool! I didnt use RB before, but i use gerrit. Do you pan to integrate it to g.o.g.o? It seems can be done by git commit hooks В письме от 28 мая 2013 23:42:17 пользователь Michael Palimaka написал: Hi, I have set up a Review Board instance[1] for testing / evaluation / whatever-you-want purposes. If you are not familiar with what happens in a review, there are a number of established Review Boards to look at.[2] This instance is currently configured for gentoo-x86, as well as a couple of overlays (but it is trivial to add more so let me know if you want your repo added too). While there are a number of options available, I personally like Review Board because it's unobtrusive - it does not disrupt usual workflow because it's only used when wanted. Have a try and see what you think. Best regards, Michael [1]: http://astralcloak.net/~kensington/rb/ [2]: https://git.reviewboard.kde.org/r/110678/ -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: cartesian product extension to keyword system
В письме от 29 апреля 2013 15:43:03 пользователь Jeroen Roovers написал: On Mon, 29 Apr 2013 16:14:51 +0900 heroxbd hero...@gentoo.org wrote: KEYWORDS=~hppa-hpux ~m68k-mint ~ppc-aix ~x64-solaris ~x86-interix[] KEYWORDS_ARCH=~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 Regardless of your chance of success in making the extra complexity manageable, I think moving the tradition KEYWORDS value to KEYWORDS_ARCH, and reusing KEYWORDS for something else , would needlessly increase the work required to migrate the portage tree. Why not leave KEYWORDS what it is right now, and expand/change its meaning using alternate variables so that you can (indefinitely) maintain backward compatibility? Its not necessary. We simply may not define KEYWORDS but only define KEYWORDS_* vars. So old package managers versions will treat that as we have empty keywords jer -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] splashutils needs a maintainer
Hi all! Well, I think best solution for fbcondecor patch is to go mainline. May be after that there will be some interest fro maintaining splashutils from non- gentoo people. В письме от 27 января 2013 23:06:35 пользователь Pacho Ramos написал: With spock retirement, splashutils became orphan. The problem is that it has a lot of unresolved bugs for a long time: https://bugs.gentoo.org/buglist.cgi?quicksearch=splashutilslist_id21218 that would need someone with more knowledge about it to maintain it (as I don't have splash on my systems for years). Also looks like splashutils is no more developed, but I don't know if we have a proper replacement for it in gentoo (most distributions are moving to plymouth, but I haven't tried if it works ok on Gentoo) Thanks for your help -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
В письме от 23 января 2013 08:03:56 пользователь Alexis Ballier написал: On Wed, 23 Jan 2013 09:24:26 +0100 Michał Górny mgo...@gentoo.org wrote: On Mon, 21 Jan 2013 10:27:30 -0300 Alexis Ballier aball...@gentoo.org wrote: To be honest, I don't know if there's other way to hide USE flags than using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split the flags per-arch, i.e. have: MULTILIB_AMD64=abi1 abi2 abi3 MULTILIB_PPC64=abi1 abi2 abi3 with appropriate USE_EXPAND_HIDDEN set by profiles. I don't like that at all. I'd go for ABI= the union of all the MULTILIB_ABIS variables (if there is no name collision) we certainly want skype to depend on libitneeds[abi_x86], not 'amd64? ( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )' Just a quick idea. How would you feel about abi_x86_32? (similarly _64, _x32) That would be almost natural names with the trick variable being ABI_X86, therefore having all the fore-mentioned advantages. The deps would look like: libitneeds[abi_x86_32] Sounds good too, I just would want it to be shared between arches that can: amd64/x86/x32, ppc/ppc64, mips, sparc32/sparc64, etc. You mean you will hide ABI_X86 USE_EXPAND on non-x86 arches, right ? This would have all the benefits I think, very good idea :) Alexis. Shared abi names are bad idea. For example mips abis : o32 n32 n64 eabi x86: x86_32 x86_x32 x86_64 Actualy first three one are equivalent in their internal behavior. But i dont think that its good idea to have one name for all. Think about multiarch installs where you can have binaries from different architectures in one system. -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] app-emulation/qemu-user mask
Hi! For cross-chroots its needed to have static qemu-$arch user translators. May be you can introduce user-static use flag for them? Also it will be cool to have init script for kvm В письме от 11 января 2013 22:45:30 пользователь Doug Goldstein написал: Just wanted to give everyone a heads up. app-emulation/qemu provides all the functionality of app-emulation/qemu-user without all the outstanding security bugs and issues the package has. For users using a cross chroot, I encourage you to look at QEMU_USER_TARGETS. I presently use an arm chroot with app-emulation/qemu. Should there truly be a missing feature, open a bug and I'll fix it. The only item I'm aware of that app-emulation/qemu does not have is the binfmt initscript. But I plan on adding that to the unstable version shortly. If there are no objections for 30 days, I'll send a treecleaner notice in 30 days and remove it 30 days after that (60 days from now).
Re: [gentoo-dev] app-emulation/qemu-user mask
В письме от 14 января 2013 00:38:06 пользователь Doug Goldstein написал: On Sun, Jan 13, 2013 at 1:45 PM, Alexey Shvetsov ale...@gentoo.org wrote: Hi! For cross-chroots its needed to have static qemu-$arch user translators. May be you can introduce user-static use flag for them? Also it will be cool to have init script for kvm USE=static is available for app-emulation/qemu. I'll get a chroot for arm setup soon and test everything to make sure its working well. It doesnt allow to build dynamik qemu-system* and static user targets With regards to the KVM init script, I'm uninterested in maintaining it and it doesn't belong in the package as it is. There's a number of submitted init scripts that are attempting to create init scripts but really they're re-inventing libvirt and ganeti, but instead poorly. Ones I know about are: https://bugs.gentoo.org/show_bug.cgi?id=321517 https://bugs.gentoo.org/show_bug.cgi?id=406043 Ghm.. Its some kind of overkill to install libvirt or gannety just for 1-2 vms
[gentoo-dev] Packages up for grabs
Hi all! Due to we dont have WiMAX networks here anymore (all of them were migrated to LTE) wimax related packages are now up for grabs as I cannot test them: net-wireless/i2400m-fw net-wireless/madwimax net-wireless/wimax net-wireless/wimax-tools -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] About unresolved bugs assigned to mobile for ages
Seems most of apps maintained by indiviual maintainers (for example i'm maintaining wimax stack) I dont know overall state of this herd Markos Chandras писал 29-10-2012 13:50: On Sun, Oct 28, 2012 at 12:26 PM, Pacho Ramos pa...@gentoo.org wrote: Hello I would like to know about mobile team status and also show that this team has important bugs assigned to them for a long time, some of them with patches (and reporters angry because of seeing things untouched for a long time). If anyone has time to join to the team and help, nice, if the team needs to drop from some packages maintainership due lack of manpower, please tell us what packages do you want up for grabs. Thanks I don't believe anyone is active in the mobile herd anymore. Probably the packages need to be moved to maintainer-needed@ so individual developers can take care of them. -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] ROMs category suggestion
May be sys-firmware? =) Rick Zero_Chaos Farina писал 2012-07-22 08:53: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/22/2012 12:12 AM, Doug Goldstein wrote: I've got a few ROMs to add to the tree and some which are already in the tree if people have a suggestion where they should live. Short list: ipxe openbios seabios sgabios vgabios sys-bios? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQC4dkAAoJEKXdFCfdEflKKHUP/1tab6d5DImIMABO9MEbQwAX j/UVCg41+nKC4Kc04bfcFjYuzU8Ncl0JTGFQIbN2yq20SO2js2yK/tLHaoo2Gh1F 1xGy1QAHSEJxnyzwLZS9m/7riWJldjFUQWpODtDMMpkiZLGRPBy3FG7i0M6xAyu/ GWqahiIsYUSlwCTI+yCbPKSjAj5RFxkGLHl0/BWq9op1qriId/lIRkAZTjXHGGgB wWWbG+3fjWclY9JhHlvGPr99qV6d1LkmapFVDTpVWbFUbMFjqxyc73EWscaBM2+N budbOtZ5uWPfAD5Qj4eUxzrM8cHzqbgBwXXTD7bGOfQNEHUVIqFKme1XuHk7/Q/P YjKlFunOZoycQpmy0OSQdxdmx5SzLTOJe94Lx0tMu6sp2cwK7Yif8yypZKXBklwc UiNAhZPndj+GlWqZhsQeAdmQ9rRa9Yh2XvhZZdR2/gzAj3Bv78io2qwNNxhgpYkf B9wAPTXnK1thhunLp71N8LGCiOUw98y1bgIX6lZvYyrMc2JK7y1HUbEA5vp01jgY n9mh/9205DRqgZWG7xZyMYlYECva9qskxPxufL7Qe100VtL5ZamNSiNynUINTsad RJEj4edr1EcvPaeFrUTzL1MrlouSgJoCe8/AYOZRf37JLZKmf3X4Tyr520g9/MY9 FxcmrcG8FDJ1c76g+Jh/ =lGpl -END PGP SIGNATURE- -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
Hi! Check kde overlay ;) we used signed commits here Rich Freeman писал 2012-06-01 16:42: On Fri, Jun 1, 2012 at 7:23 AM, Kent Fredric kentfred...@gmail.com wrote: Nope, at least not as far as I can tell, and I just implemented commit signature verification _ I've been trying to find an example of a signed commit, but can't find one anywhere, so it is hard to tell what it is doing without going through the git source carefully. If you have an example of a signed commit feel free to send it to me. Note that I am NOT interested in the output of any git operation (such as git log --show-signature, git show, etc) - these are all processed and do not reveal what is actually going on. I want a copy of the actual file containing the signature. If the signature is embedded in the commit then I want the file in the objects directory tree that contains the commit. They're just compressed text files (though it is a bit of a pain to decompress them). Not nessecarily. Given that : a file with a given content has a fixed SHA A tree is just a list of these SHA's , and that in turn is referenced by SHA, so if 2 commits have identical file content, their 'tree' sha will be the same ( in theory ). So that means, if you perform a rebase, assuming the filesystem looks the same as it did before the rebase, it will have the same SHA1 for the tree, regardless of the process of how it got to be that way. The filesystem WON'T look the same after a rebase. quick example (operations done in this order): file in commit A in master: 1 2 3 4 5 file in commit B in a branch off of master: 1 2a 3 4 5 file in commit C in master: 1 2 3 4a 5 if you merge master into the branch you'll end up with a new commit D whose parent is B that looks like: 1 2a 3 4a 5 if instead you rebase master into the branch you'll end up with a new commit D whose parent is C that looks like: 1 2a 3 4a 5 The history for the branch will no longer contain B. If there were 14 commits B1..14 you'd end up with 14 commits D1.14 that each contain the line 4a. None of them would use the same trees as B1..14, and they can't use the same signatures as a result, even if only the tree was signed. As far as the new history was concerned, line 4a was there before the branch was started. At least, that is my understanding of rebasing. Again, I'm a bit of a git novice, but I never really grokked git until I saw a presentation that didn't start with commands, but instead started out with just walking through the actual structure of the repository. Once you grok the COW model I find it all clicks into place. Rich -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
Michał Górny писал 2012-05-31 23:33: On Thu, 31 May 2012 14:18:04 -0500 William Hubbs willi...@gentoo.org wrote: On Thu, May 31, 2012 at 01:48:29PM -0400, Rich Freeman wrote: On Thu, May 31, 2012 at 12:49 PM, Robin H. Johnson robb...@gentoo.org wrote: 1. Discussion on merge policy. Originally I thought we would disallow merge commits, so that we would get a cleaner history. However, it turns out that if the repo ends up being pushed to different places with slightly different histories, merges are absolutely going to be required to prevent somebody from having to rebase at least one of their sets of commits that are already pushed. Not sure I'm following, but I will be the first to admit that I'm a git novice. Would this be aided by a convention, like only committing to master on the gentoo official repository, and any on-the-side work on places like github/etc stays in branches? Those repositories would just keep getting fed commits on master from the official repository. Iagree with this; I think we should ban merge commits on master. That would force everyone to rebase their work on current master before they commit to master which would make the history clean. What would git signing work with rebased commits? Would all of them have to be signed once again? Commits itsels still will be signed -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Ok. Since most of us want clean cut solution so i will close bug #333699 as WONTFIX -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Re: comprehensive eclass checking in repoman
Mike Frysinger писал 2012-05-25 19:42: On Thursday 24 May 2012 23:47:23 Ryan Hill wrote: Is there any sane way to handle sub-eclasses? eg. foo-base inherits foo-functions. i was thinking of extending the metadata to handle this. did you have any specific ideas in mind ? i can see inheriting say distutils should not require people to also inherit python eclasses ... -mike May we can use eclass dep graph? -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Kent Fredric писал 2012-05-24 13:02: On 24 May 2012 05:35, Alexey Shvetsov ale...@gentoo.org wrote: Full clone will be about 1G or so but no more then 2. If we will drop changelog it will be much smaller And if you use git commit signing instead of ebuild manifests, intra-commit churn will almost be negligible. :D Yep. Each signature to manifest adds ~512B of echanged data. And this will be added every commit. Also Manifest contain checksumms for all filesincluding ebuild, patches, metadata and so on. thin-manifests will contain only DIST data so they will be much smaller -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)
In gentoo git tree all git commits will be signed by commiter gpg keys (and this will be requerd!) Aaron W. Swenson писал 2012-05-25 00:00: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/24/2012 03:57 PM, Dan Douglas wrote: Git is about decentralized version control. When you clone a repo, you have your own fork. When everyone has their own branch, everyone is effectively equal. So yes you can expect much much more forking. In Git land, forks are good. There's no way to enforce that people only pull from some official source. It works out in practice so that 99% of the time people only care about a couple branches of one repository. Counterintuitively, this comes as a side- effect of git actually doing distribution properly and making it easier for everybody's workflow. The overlay model by contrast is quite broken on its own and virtually forces creation of new overlays in order to make changes without the benifits of version control (with regards to the rsync tree at least). What Github does is facilitate making it easy to fork/branch and provide a central way to push changes back into a remote through pull requests. Pull requests and other web services around git hosting are pretty much the thing that makes github worth using. From the standpoint of accepting patches, the differenc e to you is rather than (or in addition to) accepting patches through bugzilla, you can choose to accept a push directly from someone else's copy of the repo. It isn't like a wiki - everybody commits to their own repositories and pushing to a remote is on a whitelist basis just like in centralized version control. This gets us into another topic altogether. I do believe git pull-requests should go through Bugzilla. A pull-request is the equivalent to bump requests, patch fixes, and all sorts of stuff that we already handle through Bugzilla. Bugzilla also contains our history. If they happen to be needing to be pulled from github, that's fine. Definitely convenient for the contributor. We'll also need to clearly document how the pull-request is to be generated. (I vote for requiring signed pull-requests. [1]) github should not be our central point of contact. We have b.g.o for that. github should be on the fringes as a tool that we can use if we want to. [1] http://git-blame.blogspot.com.ar/2012/01/using-signed-tag-in-pull-requests.html - - Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk++oYEACgkQVxOqA9G7/aC1WgD/V33WU0Cvc/po2Evrrjk6fM4d IHt8FtD21rKfyrxmCeQA/A7t/nCJOA5UURm2ILAraPLWu598G8bKV7RNKtRKrqhQ =MVyV -END PGP SIGNATURE- -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)
Kent Fredric писал 2012-05-25 01:20: On 25 May 2012 09:14, Alexey Shvetsov ale...@gentoo.org wrote: In gentoo git tree all git commits will be signed by commiter gpg keys (and this will be requerd!) Aaron W. Swenson писал 2012-05-25 00:00: Something that still confuses me about commit signing that I haven't seen answered: How does a signed commit work with rebasing? I don't see any flag to allow rebase to sign commits rebased, and rebasing *does* change the commit fundementally in ways I'd expect to void any signature. Sure, you may not want rebasing in the master, but I sure as hell want to use it in a branch. People who maintain a long-parallel-merge history instead of rebasing their branches are on my personal shitlist =p. You can rebase signed commit untill you dont push it to master But yes i'm not sure how it works with signed commits -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
+1 for killing cvs Johannes Huber писал 2012-05-23 15:54: Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. Clean cut turns of cvs access on a given and announced timestamp, rsync-generation/updates is suspended (no input - no changes), some magic scripts prepare the git repo (according to [3], some hours duration) and we all checkout the tree (might be some funny massive load). testing git-cvsserver proses Clean cut with the additional ability to continue using cvs update/commit, - in best case - on the old checkout w/o alteration on the developers side. Clean cut forces us to clean up out dirty checkouts (I have some added directories, added ebuilds i hesitated to `repoman commit`). Plus we have to alter all our hot-wired portage mangling scripts from cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs checkout + egencache for checkout) and have an automated google-chrome bump script). But this can be accomplished on a per developer basis, and slackers don't stall the process. testing git-cvsserver forces us all to test these cvs'ish scripts and behaviours against a git-cvsserver and report. We all know that this test-runs will never happen, stalling this bug till infinity. Plus infra/subset of devs marshalling the migration get stuck between fixing git issues and git-cvsserver. *if you still read this* *wow* Please discuss my arguments and come to the conclusions to RESO/WONT-FIX testing git-cvsserver, make a clean cut and remove this bug from the blockers of [TRACKER] portage migration to git. My lengthy 2 cents. [1] https://bugs.gentoo.org/333531 [2] https://bugs.gentoo.org/333699 [3] https://bugs.gentoo.org/333705#c2 - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW =jXLQ -END PGP SIGNATURE- I support RESOLUTION WONTFIX, if nobody cares about the bug since it was opened it is obvious out of interest. There is no reason to support jurassic software. Clean cut++ Cheers -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Michał Górny писал 2012-05-23 19:33: On Wed, 23 May 2012 14:42:37 +0200 Michael Weber x...@gentoo.org wrote: *if you still read this* *wow* Please discuss my arguments and come to the conclusions to RESO/WONT-FIX testing git-cvsserver, make a clean cut and remove this bug from the blockers of [TRACKER] portage migration to git. Kill it! And while we're at it, kill ChangeLogs as well! /me hides... Well this can be done with *meaningfull* git commit messages =D so +1 -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Robin H. Johnson писал 2012-05-23 19:47: On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote: i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. The primary reasons to continue to support CVS-style access via git-cvsserver: 1. Lightweight partial/subtree checkouts - Git has implemented subtree checkouts, but they still bring down a fairly large packfile. 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS) Isnt git works with shallow clone? like # git clone --depth 1 or any other desired value git+ssh://gitrepo.uri::repo So you can clone in this manner and push changes back Also for depth = 1 pack size will be similar to gzipped rsync snapshot (~40M) If we can get rid of #2, we're willing to live with #1. Clean cut turns of cvs access on a given and announced timestamp, rsync-generation/updates is suspended (no input - no changes), some magic scripts prepare the git repo (according to [3], some hours duration) and we all checkout the tree (might be some funny massive load). 1. You will be given git bundles instead of being allowed to do initial clone. That way it's just a resumable HTTP download. 2. rsync generation is NOT going away. Users will still be using it. -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Matt Turner писал 2012-05-23 19:59: On Wed, May 23, 2012 at 12:47 PM, Robin H. Johnson robb...@gentoo.org wrote: 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS) Please don't go to this trouble for the ability to commit to portage on *really* slow systems. Isnt cvs too sloow on mips? git is much more faster. Same for arm. About big repos, well why not use shallow cloned repo. It will work with plane history -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Robin H. Johnson писал 2012-05-23 19:47: On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote: i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. The primary reasons to continue to support CVS-style access via git-cvsserver: 1. Lightweight partial/subtree checkouts - Git has implemented subtree checkouts, but they still bring down a fairly large packfile. 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS) If we can get rid of #2, we're willing to live with #1. Clean cut turns of cvs access on a given and announced timestamp, rsync-generation/updates is suspended (no input - no changes), some magic scripts prepare the git repo (according to [3], some hours duration) and we all checkout the tree (might be some funny massive load). 1. You will be given git bundles instead of being allowed to do initial clone. That way it's just a resumable HTTP download. 2. rsync generation is NOT going away. Users will still be using it. Another good point for repo size https://git.wiki.kernel.org/index.php/GitFaq#How_do_I_use_git_for_large_projects.2C_where_the_repository_is_large.2C_say_approaching_1_TB.2C_but_a_checkout_is_only_a_few_hundred_MB.3F_Will_every_developer_need_1_TB_of_local_disk_space.3F -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Robin H. Johnson писал 2012-05-23 20:19: On Wed, May 23, 2012 at 07:58:17PM +0300, Alexey Shvetsov wrote: Isnt git works with shallow clone? like # git clone --depth 1 or any other desired value git+ssh://gitrepo.uri::repo So you can clone in this manner and push changes back Also for depth = 1 pack size will be similar to gzipped rsync snapshot (~40M) The shallow clone is still a shallow clone of the entire repo, and you get the subtree checkout as just part of that. Shallow clones are also read-only last I checked. That isnt true =) you can commit from shallow clone if and only if original repo doesnt have a branching and merging points before and after shallow clone point respectively -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Rich Freeman писал 2012-05-23 20:32: On Wed, May 23, 2012 at 1:22 PM, Alexey Shvetsov ale...@gentoo.org wrote: That isnt true =) you can commit from shallow clone if and only if original repo doesnt have a branching and merging points before and after shallow clone point respectively Is that going to be a practical condition to maintain? And how big will the repository actually be? Are we talking a GB or two, or something orders of magnitude larger? Rich Full clone will be about 1G or so but no more then 2. If we will drop changelog it will be much smaller -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Arun Raghavan писал 2012-05-23 22:37: I, for one, think we should stay with CVS and leave all this git Linusware to the new-fangled Fedora kids with their fancy init systems and tight coupling. CVS was good enough for my grandfather, and it's good enough for you. CVS is damn slow. On every cvs up it should stat *all* files and cvs entryes in current state its ~212k files in gentoo-x86. It will be sloow on every machine unless you put all this files in ram Actual number of usefull files is only about ~60k (ebuilds,eclasses,metadata.xml,patches) Its comparable to linux kernel git tree ~42k files And yes git is much more faster. PS if ibm s/360 was good for my grandfather why we all use modern intel pc? Lets stay under 1 MIPS machines like s/360 -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] amd64-fbsd profile marked 'stable'
Hi! May be you can share stages and install instructions for this? Alexis Ballier писал 2012-05-08 15:33: Hi, I've just marked the profile 'default/bsd/fbsd/amd64/9.0' as 'stable' in profiles.desc. I've been careful not to keyword anything with broken deps, and its now forbidden. It is the first g/fbsd profile marked as such. Consequences for devs: broken deps are not allowed anymore; people are, like for standard arches, expected to drop keywords and fill a rekeywording bug. Rationale: - x86-fbsd has been a 'dev' profile for so long that the majority of the packages have broken deps, meaning moving it to a 'stable' profile is almost impossible. I do not want to repeat this error for amd64-fbsd - people usually do not run repoman -d, and as such, it is common to get (core or not) packages that are uninstallable on g/fbsd. This wont happen anymore and will make devs and users happier :=) cons: there's no stable amd64-fbsd keyword, i suppose that if we want some day to stabilize it, it'll be hard with a 'stable' profile, but we can temporarily switch it back to 'dev' while doing it, and without preventing broken deps it'll be almost impossible to do this anyway. Regards, A. -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] [GSoC2012] Cross Container Support Project
Hi! Well i have 2 arm lxc containers on amd64 machine. Its works good if qemu support most of needed cross arch instructions Jing Huang писал 2012-03-23 13:36: Hi Everyone, I am a student at Peking University in China. I am very interested in the project of Cross Container Support(). I have some ideas about the project. Please help me to examine the thoughts. First, I think downloading stage and portage packets into specified directory each time needs to be impoved(). It needs to build execution environment every time. So it is not convenient. On the other hand, the files in specified directory would be modified by some process potentially. It is not an isolated execution environment at all. Therefore, I would make some img files for the each arch, including arm, mips, etc. The img file contains arch-stage and portage. When creating the qemu-user container, the iniscript mounts the img file into specified directory then chroot to it. Second, if the process accesses disk frequently, I would to make a tmpfs file for the qemu-user container. The process in the container is running on tmpfs file and been sped up. Third, I would custom a lightweight qemu-user container for the specified process if necessary. In my previous work, I made a custom ramdisk VM for the process by modifying the mkinitrd script. With the help of “ldd –v ” command, I could get the shared libraries of the process and packet them into ramdisk. But in Gentoo, maybe I could custom the qemu-user container using the USE label. In my proposal, this project uses a small quantity of bash to implement just the core tools (create, destroy, enter). In simpler terms, I plan to implement them in this way: 1. create routine # qemu_container_create config_file The config_file specifies arch, arch-img file, chroot directory, additional args of qemu(like -cpu cortex-a8). Then the create routine will execute as: 1). If having the arch-img then mount it into chroot directory. 2). If not, make a new img file, download stageballportage, unpack them to the chroot directory. 2). modprobe binfmt_misc and register the qemu-user-arch to the binfmt_misc. 3). install the static qemu-user into the chroot directory and mount the required directories. 4). register this new container to our managment tool. The register info includes container_id, stageball version, stageball arch, chroot directory, etc. 2. enter routine #qemu_container_enter container_id The enter routine opens a terminal and chroot into the environment. The management tool should also set the container is in running state. 3. destroy routine #qemu_container_destroy container_id 1). exits from chroot environment 2). unmount stuff when not in use 3). clear the qemu-user-arch in binfmt_misc register file (maybe other containers use it) 4). remove the container info from managment tool Besides these routines, I would also implement container_list and container_export routines. The former lists the info/state of containers. The latter is used to export system images. Questions: 1). Why integrate qemu-user container with crossdev? Crossdev is a cross compiler. The qemu-user container not only compiles the heterogeneous programs but also tests them. I thought if the qemu-user container was good enough, it could replace the crossdev. 2). An additional task is to support layered systems so native userspace can be used to further speed up the process (hybrid chroot). I don't very understand the task. Could someone help me and explain the “hybrid chroot”? Would someone give me some suggestions? Any comments will be much appreciated. Jing Huang. -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] x32 fun pants
Hi all! Is it accepted for merge into kernel mainline for 3.2? Actualy this abi looks like n32 mips abi. PS why not merge all x86 abis into one keyword? because x86_32 x86_64 x86_x32 are only abis of x86. Also we dont have different keywords for different mips abis (64bit and 32bit ones) On Thu, 15 Sep 2011 15:34:06 -0400, Mike Frysinger wrote: ive converted my system over to x86/amd64/x32 multilib for funs. but i can see how some people wont want all three all the time. so the question is how we want to make this available to users at the release/profile level. background: x32 is a new ABI that runs on 64bit x86_64 processors. see [1]. you'll need gcc-4.7+, binutils-2.21.50+, glibc-2.15+, and linux-3.2+. KEYWORDS wise, i'd like to avoid having to add x32 everywhere. instead, reusing amd64. only downside is the existing USE=amd64 behavior, but we can address that by making MULTILIB_ABIS a USE_EXPAND (i think this came up before with the portage multilib discussion). release wise, we could ship a single multilib stage (x86/amd64/x32) and make it easy to convert to a subset. that way we still need only one. other thoughts ? -mike [1] https://sites.google.com/site/x32abi/ -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] fhs and multilib question
Hi all, There is a draft of fhs-3.0[1] Also i think that lib should be symlink to lib64 on 64bit systems its at least will be consistent My 0.02 $CURRENCY. [1] http://dev.linuxfoundation.org/~licquia/fhs-3.0-drafts/fhs.html On Sun, 11 Sep 2011 11:50:28 -0500, William Hubbs wrote: Hi all, I have been dealing with a bug in openrc which prompted me to look at our directory structure for libraries on 64 bit systems. The bug will be referenced below[1]. The problem in the bug isn't the location of libraries, but the fact that there is a mount point stored under the library directories. Here is what I've found in fhs [2]. - /lib should always exist on all architectures. - /lib64 should only exist on amd64, ppc64, sparc64 and s390x. It should hold 64 bit libraries, and /lib should hold 32 bit (or 31 bit on s390x) libraries. - /lib should hold 64 bit libraries on ia64. - FHS mentions /lib32 but doesn't really define what goes in it, and with the definition of when /lib64 is to be used, there doesn't seem to be a need for /lib32. - Also, it seems questionable that /lib is a symlink to /lib64 on non-multilib systems. I think we should still have separate /lib and /lib64 directories. Constructive criticism of this idea, thoughts, etc, are welcome. If there is no opposition, what would it take for us to do this? Thanks, William [1] http://bugs.gentoo.org/show_bug.cgi?id=381783 [2] http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64 -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] rfc: using /libexec
Moving things as openrc to /usr/libexec will effectevely barake old systems with separtae / and /usr. So it isnt good idea On Tue, 6 Sep 2011 16:45:43 -0500, William Hubbs wrote: On Tue, Sep 06, 2011 at 05:21:40PM -0400, Mike Frysinger wrote: On Tuesday, September 06, 2011 14:46:06 William Hubbs wrote: we just got the following bug report for openrc today [1]. On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and this causes breakage in openrc. that specific report sounds like using /run would fix things ? I haven't really looked at using /run for anything in openrc on linux, but that might be possible once we have it installed in baselayout. I don't think it would fix this issue though. as for the paths, openrc should be using the paths it installs into. so if we're installing into /lib64/rc..., then that's what we should be using. We are installing into /lib/rc, but /lib is a symlink on 64 bit systems, so we are having an issue resolving the path. The simplest fix for this would be for us to add /libexec to baselayout and start using it for platform-agnostic code. We have /usr/libexec, so I don't know why we don't have /libexec. Should we? same answer as last time people have asked about /libexec: no. we dont need it, and it's ugly cruft that no other distro ive seen uses, and this isnt something we need to differentiate Gentoo. The same thing should be applied to /usr/libexec then shouldn't it? (just asking for more info here) William -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] rfc: using /libexec
On Wed, 7 Sep 2011 11:27:05 +0200, Michał Górny wrote: On Wed, 07 Sep 2011 12:17:21 +0300 Alexey Shvetsov ale...@gentoo.org wrote: Moving things as openrc to /usr/libexec will effectevely barake old systems with separtae / and /usr. So it isnt good idea Old systems should migrate to initramfs, like it was already pointed out before. Breakage is already there, you just don't notice it. Almoust all of my systems have lvm and separated /usr. And all of them still boot fine -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
[gentoo-dev] Progress on cvs-git migration
Hi all! Is there any progress since last update on cvs-git migration? -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Re: gentoo-x86 commit in sys-cluster/torque: metadata.xml ChangeLog torque-2.5.6-r1.ebuild
On Tue, 5 Jul 2011 13:09:13 -0400, Justin Bronder wrote:
On 03/07/11 23:37 +, Alexey Shvetsov (alexxy) wrote:
alexxy 11/07/03 23:37:20
Modified: metadata.xml ChangeLog
Added:torque-2.5.6-r1.ebuild
Log:
Add blocker to slurm and add maui scheduler to rdepend
USE=maui doesn't change anything on the users system aside from
adding
another package they do not need in order to use Torque. I'd rather
users
install maui by themselves if they want to replace pbs_sched.
Unless you feel strongly, I'm going to back out that part of this
changeset.
Well its a good way to indicate that torque need maui with pbs use flag
if it want to use it.
Thanks,
(Portage version: 2.2.0_alpha43/cvs/Linux x86_64)
Revision ChangesPath
1.8 sys-cluster/torque/metadata.xml
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-cluster/torque/metadata.xml?rev=1.8view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-cluster/torque/metadata.xml?rev=1.8content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-cluster/torque/metadata.xml?r1=1.7r2=1.8
Index: metadata.xml
===
RCS file: /var/cvsroot/gentoo-x86/sys-cluster/torque/metadata.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- metadata.xml26 Jun 2011 00:47:16 - 1.7
+++ metadata.xml3 Jul 2011 23:37:20 - 1.8
@@ -6,9 +6,10 @@
emailjsbron...@gentoo.org/email
/maintainer
use
- flag name='cpusets'Enable pbs_mom to utilize linux cpusets if
available./flag
- flag name='drmaa'Enable the Distributed Resource Management
Application API./flag
- flag name='munge'Enable authentication via munge./flag
- flag name='server'Enable compilation of pbs_server and
pbs_sched./flag
+ flag name='cpusets'Enable pbs_mom to utilize linux cpusets if
available/flag
+ flag name='drmaa'Enable the Distributed Resource Management
Application API/flag
+ flag name='maui'Enable maui scheduler support/flag
+ flag name='munge'Enable authentication via munge/flag
+ flag name='server'Enable compilation of pbs_server and
pbs_sched/flag
/use
/pkgmetadata
1.118sys-cluster/torque/ChangeLog
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-cluster/torque/ChangeLog?rev=1.118view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-cluster/torque/ChangeLog?rev=1.118content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-cluster/torque/ChangeLog?r1=1.117r2=1.118
Index: ChangeLog
===
RCS file: /var/cvsroot/gentoo-x86/sys-cluster/torque/ChangeLog,v
retrieving revision 1.117
retrieving revision 1.118
diff -u -r1.117 -r1.118
--- ChangeLog 2 Jul 2011 18:12:32 - 1.117
+++ ChangeLog 3 Jul 2011 23:37:20 - 1.118
@@ -1,6 +1,12 @@
# ChangeLog for sys-cluster/torque
# Copyright 1999-2011 Gentoo Foundation; Distributed under the GPL
v2
-# $Header: /var/cvsroot/gentoo-x86/sys-cluster/torque/ChangeLog,v
1.117 2011/07/02 18:12:32 armin76 Exp $
+# $Header: /var/cvsroot/gentoo-x86/sys-cluster/torque/ChangeLog,v
1.118 2011/07/03 23:37:20 alexxy Exp $
+
+*torque-2.5.6-r1 (03 Jul 2011)
+
+ 03 Jul 2011; Alexey Shvetsov ale...@gentoo.org
+torque-2.5.6-r1.ebuild,
+ metadata.xml:
+ Add blocker to slurm and add maui scheduler to rdepend
02 Jul 2011; Raúl Porcel armi...@gentoo.org
torque-2.4.14.ebuild:
alpha/ia64/sparc stable wrt #372959
1.1 sys-cluster/torque/torque-2.5.6-r1.ebuild
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-cluster/torque/torque-2.5.6-r1.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-cluster/torque/torque-2.5.6-r1.ebuild?rev=1.1content-type=text/plain
Index: torque-2.5.6-r1.ebuild
===
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/sys-cluster/torque/torque-2.5.6-r1.ebuild,v
1.1 2011/07/03 23:37:20 alexxy Exp $
EAPI=2
inherit flag-o-matic eutils linux-info
DESCRIPTION=Resource manager and queuing system based on OpenPBS
HOMEPAGE=http://www.clusterresources.com/products/torque/;
SRC_URI=http://www.clusterresources.com/downloads/${PN}/${P}.tar.gz;
LICENSE=torque-2.5
SLOT=0
KEYWORDS=~alpha ~amd64 ~hppa ~ia64 ~mips ~ppc ~ppc64 ~sparc ~x86
IUSE=cpusets +crypt doc drmaa kernel_linux maui munge server
+syslog threads tk xml
# ed is used by makedepend-sh
DEPEND_COMMON=sys-libs/ncurses
sys-libs/readline
munge? ( sys-auth/munge )
tk? ( dev-lang/tk )
syslog? ( virtual/logger )
!games-util/qstat
DEPEND=${DEPEND_COMMON}
sys
[gentoo-dev] [RFC] Add support for RDMA enabled devices in main tree
Hi all! I'm working on putting infiniband support to main tree. Currently infiniband related stuff hosted in science overlay in sys-infiniband [1] category (this category currently contains ~25 packages but they will be ~40) so i wanna move them as whole category. Also i'm going to add USE_EXPAND for infiniband userspace drivers: libmlx4 libmthca libehca libcxgb3 Any objections about moving this stuff to tree? PS some in-tree stuff already has infiniband use flag so i'd like to make it global or may be rename it to rdma [1] http://git.overlays.gentoo.org/gitweb/?p=proj/sci.git;a=tree;f=sys- infiniband;h=5442f68fcaa8cedde34772915c605fdbab8d5541;hb=HEAD -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Add support for RDMA enabled devices in main tree
On Thursday 30 of June 2011 14:47:06 Mike Frysinger wrote: On Thu, Jun 30, 2011 at 14:40, Alexey Shvetsov wrote: Also i'm going to add USE_EXPAND for infiniband userspace drivers: libmlx4 libmthca libehca libcxgb3 use will be something like OPENIB_DRIVERS=mlx4 mthca ehca cxgb3 Honestly i can only tests first two. Also since mlx4 ib driver wants kernel with xrc support i gonna add 'cluster- sources' to tree and use flag 'xrc' to virtual/linux-sources-2.6 so sys- infiniband/libmlx4 will depend on it. So if there will be no objections i'll proceed with this stuff =) And I'll move it to tree in an hour or so. should it be based on the hardware family rather than the lib name ? Any objections about moving this stuff to tree? i object to it not being done already ! ;) -mike -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Add support for RDMA enabled devices in main tree
On Thursday 30 of June 2011 20:54:21 Robin H. Johnson wrote: On Thu, Jun 30, 2011 at 10:40:26PM +0400, Alexey Shvetsov wrote: I'm working on putting infiniband support to main tree. Currently infiniband related stuff hosted in science overlay in sys-infiniband [1] category (this category currently contains ~25 packages but they will be ~40) so i wanna move them as whole category. Also i'm going to add USE_EXPAND for infiniband userspace drivers: Why a new category of sys-infiniband vs. existing sys-* categories. I thought I had seen some existing infiniband packages lurking in the tree. Because its very scpecific stuff containing system libs and userspace drivers and daemons that will make ib hw functional =) -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
Hi all! Why not use redmine as sources.gentoo.org? 2011/1/22 Theo Chatzimichos tampak...@gentoo.org: On Saturday 22 January 2011 06:20:27 Donnie Berkholz wrote: I don't see any particular reason to distinguish between the main tree and overlays in this structure. Just do something common for both, like tree/ or ebuilds/ or packages/. In the same vein, there's no good reason I can think of to discriminate between overlays that are project vs personal, since either can be supported or unsupported. And I don't see a reason to merge the huge overlays list with the official gentoo tree. They are totally different things, and a future alternative to viewvc in sources.gentoo.org (maybe trac-git) should reflect that. If we show a huge list with ebuild repos to public (especially to new to gentoo) without separating the official tree (including user/unofficial/bad-shaped ones), I suppose we'll give the impression we are like debian, where the user needs the multimedia overlay to get multimedia ebuilds, or the kde overlay to install kde. For the second part of your question, Ryan's responce is perfect. -- Theo Chatzimichos (tampakrap) Gentoo KDE/Qt, Planet, Overlays -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] MULTI_ABI support addition to main tree portage
Well =) This will be killer feature in gentoo =P Also what about more complex arhes than ia32? like mips of ppc? PS also with this feature seems amd64 and x86 can be merged in one arch (like it was done in kernel) since its only abis of ia32 2010/12/1 Thomas Sachau to...@gentoo.org: Hi, i have already written about this some months ago and updated the code in relation to the comments especially from vapier. Basicly, it does now first set abi-specific vars (like CC, CFLAGS and others (setup_abi_env function in bin/auto-multilib.sh contains the full list), then does build the package as usual. If additional ABIs are requested, it checks after src_install, if there are possible ABI-specific files (libs, headers or, if requested for every ABI, also binaries). If those are found, the image dir is moved away and a new run is started, where again at start abic-specific vars are set and then the complete src* phases are run. Once all requested ABIs are done, the image dirs are merged into the final image dir. The following pkg_* phases are each running for every ABI. Currently, only different libs and headers are installed by default, binaries will be the ones from the default ABI, unless you tell portage to install binaries for all requested ABIs, in which case a wrapper will select the ABI-specific binary depending on the environment. The current implementation uses a USE-dep like way internally to satisfy the needed dependencies, so that e.g. 32bit libs on a 64bit platform get their required dependencies built with 32bit libs installed. For the rare case, where the crosscompile does fail and there is only a need for the binary and no linking against the libs, i have also a var, which disables this auto-dependency calculation for specified packages. For the user interface, portage shows a USE_EXPANDed var, which contains the avaidable ABIs, as an example for emerge -pv media-libs/jpeg: [ebuild R ] media-libs/jpeg-8b USE=-static-libs MULTILIB_ABI=amd64 x86 Those ABIs can be handled like USE flags, in this case, they are multilib_abi_amd64 and multilib_abi_x86, so you can use those USE flags to enable/disable specific possible ABIs either globally or per package. The basic implementation can be used without changing main tree ebuilds or eclasses, but e.g. for the replacement of emul-* libs, this will require EAPI-support for ABI-specific USE-deps for binary-only packages or packages like wine. I would first like to see, if there are any bigger concerns especially with the implementation and how it is supposed to work. If there are no such concerns or if they have been resolved, i would like to request some help for the documentation and PMS-patch related work. For install instructions, please have a look at [1], the code can be found in the multilib branch of portage git repo at [2]. While i did not yet get to the implementation of it, i would also like to propose something similiar for languages (like python, ruby or others), so that the basic parts are inside the PM and we can drop the different ways of implementation and allow users a much more fine-grained control on a per package base (in relation to the current way python eclass based very complex implementation works). [1]: http://github.com/sjnewbury/multilib-overlay/tree/portage-multilib/doc [2]: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=shortlog;h=refs/heads/multilib -- Thomas Sachau Gentoo Linux Developer -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Re: MULTI_ABI support addition to main tree portage
Well ok =) i call it ia32 since its original name of this arch however it can be better called x86 (x86_32 and x86_64) PS seems many users were confused with ia64 since they associate it with core2 and nahalem 2010/12/1 Diego Elio Pettenò flamee...@gmail.com: Il giorno mer, 01/12/2010 alle 22.11 +0300, Alexey Shvetsov ha scritto: PS also with this feature seems amd64 and x86 can be merged in one arch (like it was done in kernel) since its only abis of ia32 I would suggest against that. For the kernel it's somewhat easier, but for userland, x86 and amd64 are definitely far enough that I wouldn't be surprised if it'll take a few more years before we can easily consider the two keywords a single one. Just think of a relatively-common situation. void *bar = foo(); with foo implicitly declared. On 32-bit userland it'll be all fine, but will crash badly on 64-bit userland. And this is without adding to the necessity of PIC, and the rest of little details that this brings with it. For the sake of safety, let's _not_ merge this, as we have said too many times for me to dig up. And finally, let's not call it ia32. No matter what Intel wants it to be called, if you were to call it like that, you'd just have a number of people asking why their ia64 stage don't work. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-apps/drupal: drupal-5.23.ebuild ChangeLog drupal-6.19.ebuild drupal-6.16.ebuild drupal-6.17.ebuild drupal-5.22.ebuild
Ok =) Next time i'll add bug numbers =) Actualy i simply forgot about them. 2010/8/17 Alex Legler a...@gentoo.org: On Tue, 17 Aug 2010 10:46:10 +0400, Peter Volkov p...@gentoo.org wrote: В Пнд, 16/08/2010 в 18:04 +, Alexey Shvetsov (alexxy) пишет: alexxy 10/08/16 18:04:52 Modified: ChangeLog Added: drupal-5.23.ebuild drupal-6.19.ebuild Removed: drupal-6.16.ebuild drupal-6.17.ebuild drupal-5.22.ebuild Log: [www-apps/drupal] Version bump Always reference bug number and mention people that spent time reporting problems in our bugzilla. Please, add bug # and attribution into ChangeLog. Also with version bump it's always good idea to keep previous version to allow re-installation of previous versions in the case of regressions. https://bugs.gentoo.org/show_bug.cgi?id=323399 That's rather https://bugs.gentoo.org/show_bug.cgi?id=332541 I agree that the bug # should be referenced, but as for removing the old versions, that's something we usually ask people to do after bumping packages with security issues to minimize the risk of people installing possibly vulnerable versions. -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
[gentoo-dev] OpenIB stuff in gentoo
Hi all! I'm currently maintaining OFED[1] stack in science overlay[2]. There are 26 packages in sys-infiniband category but its going to grow for 10 more. Also there is eclass to unpack complicated OFED distribution tarball. So what will be best place to put this software in tree? Should i keep the sys-infiniband category or use some already available one? [1] http://www.openfabrics.org [2] http://git.overlays.gentoo.org/gitweb/?p=proj/sci.git -- Alexey 'Alexxy' Shvetsov Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
On Пятница 09 октября 2009 21:57:07 Matthias Schwarzott wrote: Hi there! As some of you have waited long for this to happen, sys-apps/openrc-0.5.1 is there. It has a default enabled (eapi-1) useflag oldnet to install the old-style network scripts called net.*. Regardless of this use-flag, the new init-script /etc/init.d/network is always installed. For transition to new-style network script there is something todo I think. Unordered list of todos: * hotplug? at least udev does explicitly call in net.* scripts * New systems should get old or new scripts? * does new scripts already can do all that was possible with net.* ? So far I hope the update does not break any system. In case this happens nevertheless open a bug as usual. Regards Matthias I think we should have unicode=yes in rc.conf by default if we have +unicode in USE -- Alexey 'Alexxy' Shvetsov Gentoo/KDE Gentoo/MIPS Gentoo Team Ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI and system packages
On Воскресенье 20 сентября 2009 11:47:30 Rémi Cardona wrote: Le 20/09/2009 02:31, Ryan Hill a écrit : If not, when can we drop support for old EAPIs? Your opinions please. Let's drop it now. We've waited long enough. Portage with EAPI=2 has been stable for more than a year. Rémi Yes its good idea to drop EAPI2 from tree, but we should provide a way to upgrade for people that don't upgrades recently. So we can: 1 create a portage snapshot 2 write mini how to about upgrade 3 then drop EAPI=0 and EAPI=1 from tree to simplify tree -- Alexey 'Alexxy' Shvetsov Gentoo/KDE Gentoo/MIPS Gentoo Team Ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Gentoo stats server/client @ 2009-08-22
Hi all! seems smoltSendProfile doesnt work with unicode locales =) 100%] x11-wm/twm-1.0.4 Traceback (most recent call last): File /usr/lib/python2.6/site-packages/smolt/client/sendProfile.py, line 211, in module % excerpts UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 0: ordinal not in range(128) 2009/8/26 Sebastian Pipping webmas...@hartwork.org: Christian Faulhammer wrote: Hi, Sebastian Pipping webmas...@hartwork.org: Christian Faulhammer wrote: That's a nice starting point to have a look if they aren't installed they are unpopular or because they fail to build (which makes them a candidate for removal). I'm not following - how would we find out about the reason a package is never reported installed? Own tests? Bugzilla? It is only to get an idea which packages might be at their of life. I see, good idea. Sebastian -- Alexey 'Alexxy' Shvetsov Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] New 10.0 LiveDVD release enhancements
Hi all! Also i think it wil be good idea to include parted into liveDVD since its only tool that support gpt partition tables =) 2009/8/23 James Homuth ja...@the-jdh.com: -Original Message- From: Samuli Suominen [mailto:ssuomi...@gentoo.org] Sent: August 22, 2009 10:47 AM To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] New 10.0 LiveDVD release enhancements Fernando V Orocu (likewhoa) has been working on getting the 10.0 LiveDVD images in shape for the Gentoo 10th year anniversary release. We need some assistance in terms of LiveDVD testers, user suggestions for new packages software testers since there will be over 100+ new packages on this release dvd. We are looking for constructive feedback and ideas from both the developer community and user community. We want this 10th year anniversary release DVD to reflect our accomplishments over the year and your feedback is highly appreciated. Below are a few of the goals for the the LiveDVD release. 1. Supply both 32/64bit stable kernels 2. Enable HybridISO for the images 3. KDE/GNOME Desktop Environment 4. Speak-Up Functionality 5. your suggestions here Some links.. http://bugs.gentoo.org/281827 http://weboperative.com/gentoo/downloads/livecds svn co svn://anonsvn.gentoo.org/releng/trunk/releases/10.0 -Samuli How would a non-developer go about participating in the test? -- Alexey 'Alexxy' Shvetsov Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] gcc-4.4 unmasking soon
Hi! I'm already use gcc-4.4.0/gcc-4.4.1 and whole system was rebuild with new gcc (including kde-4.2.x/4.3.x and openoffice). Also i noticed that some scientific software works better with gcc-4.4.x (like gromacs and gamess) On Среда 05 августа 2009 05:15:57 Mark Loeser wrote: I'd really like to unmask gcc-4.4.1 soon, as in the next week or so. If you could please install it and test it out, I would appreciate it. Also, if you have any gcc 4.4 porting bugs assigned to a herd that you are a part of, resolving those bugs would help a lot. Thanks to all that have contributed and helped already, -- Alexey 'Alexxy' Shvetsov Gentoo/KDE Gentoo/MIPS Gentoo Team Ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [RFC] USE_EXPAND for qemu unified ebuild
On Суббота 16 мая 2009 03:18:09 Luca Barbato wrote: Luca Barbato wrote: Duncan wrote: Namespace pollution? QEMU_USER_TARGETS and QEMU_SOFTMMU_TARGETS, maybe? Right, anyway either one or two vars, anybody has a strong feeling towards one of them or against any of them? QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS, that's it. -USE_EXPAND=APACHE2_MODULES APACHE2_MPMS FOO2ZJS_DEVICES MISDN_CARDS FRITZCAPI_CARDS FCDSL_CARDS VIDEO_CARDS DVB_CARDS LIRC_DEVICES INPUT_DEVICES LINGUAS USERLAND KERNEL ELIBC CROSSCOMPILE_OPTS ALSA_CARDS ALSA_PCM_PLUGINS LCD_DEVICES CAMERAS NETBEANS_MODULES +USE_EXPAND=APACHE2_MODULES APACHE2_MPMS FOO2ZJS_DEVICES MISDN_CARDS FRITZCAPI_CARDS FCDSL_CARDS VIDEO_CARDS DVB_CARDS LIRC_DEVICES INPUT_DEVICES LINGUAS USERLAND KERNEL ELIBC CROSSCOMPILE_OPTS ALSA_CARDS ALSA_PCM_PLUGINS LCD_DEVICES CAMERAS NETBEANS_MODULES QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS alpha - userspace emulation target armeb - userspace emulation target arm - userspace emulation target cris - userspace emulation target i386 - userspace emulation target m68k - userspace emulation target mips64el - userspace emulation target mips64 - userspace emulation target mipsel - userspace emulation target mips - userspace emulation target ppc64abi32 - userspace emulation target ppc64 - userspace emulation target ppc - userspace emulation target sh4eb - userspace emulation target sh4 - userspace emulation target sparc32plus - userspace emulation target sparc64 - userspace emulation target sparc - userspace emulation target x86_64 - userspace emulation target arm - system emulation target cris - system emulation target i386 - system emulation target m68k - system emulation target mips64el - system emulation target mips64 - system emulation target mipsel - system emulation target mips - system emulation target ppc64 - system emulation target ppc - system emulation target sh4eb - system emulation target sh4 - system emulation target sparc - system emulation target x86_64 - system emulation target ppcemb - system emulation target If anybody is against it please tell ^^ lu its realy a good idea to make targets for qemu selectable =) since not all targets work all time at the same condition. -- Alexey 'Alexxy' Shvetsov Gentoo/KDE Gentoo/MIPS Gentoo/Sci Gentoo Team Ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Deprecating EAPI0
Alec Warner wrote: I am interested in the number of ebuilds at specific APIs in the tree, do you have those numbers? Basically, how much work is this (raw ebuild count)? Total ebuilds 26209 EAPI0 ebuilds 22880 EAPI1 ebuilds 1855 EAPI2 ebuilds 1474 this numbers based on regexps =) -- Alexey 'Alexxy' Shvetsov Gentoo/KDE Gentoo/MIPS Gentoo/SCI Gentoo Team Ru signature.asc Description: This is a digitally signed message part.
