Re: [gentoo-dev] [Fwd: [gentoo-automated-testing] BROKEN: repository became broken!]
On 22:16 Mon 01 Feb , Andreas K. Huettel wrote: > Am Montag, 1. Februar 2016, 21:30:41 schrieb Mike Frysinger: > > On 01 Feb 2016 19:55, Patrice Clement wrote: > > > > New issues: > > > > https://qa-reports.gentoo.org/output/gentoo-ci/780f65b/output.html#dev-> > > > > > > libs/efl > > > > > > This commit is breaking the tree: > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=97a6aec > > > > > > I did try to work around the issue you've introduced when but the > > > enlightenment eclasses are a bit of mystery to me and I eventually gave > > > up. > > > > > > Could you revert this commit and fix this issue? > > > > the issue is that efl-1.15.2 is marked stable for alpha/ia64/sparc, and > > it depends on app-i18n/ibus, but commit 97a6aec deleted the only ibus > > ebuild that was marked stable for those arches. > > > > it can be fixed in a few ways (i'm listing in order of preference): > > (1) mark a newer ibus stable > > (2) revert that commit to re-add the old stable ebuilds > > (3) add USE=ibus to package.use.stable.mask for these arches > > (4) degrade all packages for these arches to unstable > > -mike > > I took the liberty of doing (2) and reverted the commit. Not sure why this > needs so much discussion; after all a broken tree is always suboptimal. > > Now there's lots of time to come up with a better solution. > thanks for doing this yes, 2) is the easiest and quickest way to fix.. -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55 signature.asc Description: Digital signature
Re: [gentoo-dev] Package up for grabs: dev-vcs/git-sizer
On 00:29 Mon 14 Feb , Ulrich Mueller wrote: > I am no longer interested in maintaining this package. > It has no open bugs, but is one release behind upstream. > I will take care it -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55
Re: [gentoo-dev] Packages up for grabs: e.g. www-servers/nginx, www-apps/nikola, app-admin/rsyslog, ...
On 11:28 Sun 05 Jun , Joonas Niilola wrote: > Full list: > > www-apps/nextcloud-notify_push will take this one as I'm using nextcloud.. but, would be more than happy if anyone want to co-maintain.. -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55
Re: [gentoo-dev] Packages up for grabs: gui-libs/wlroots, app-text/scdoc, net-fs/sshfs and more
Hi Folks On 09:58 Sun 14 Aug , Joonas Niilola wrote: > Hey, > > these packages are up for grabs: > net-fs/sshfs can take this one as I do occasionally use it but feel free to co-maintain if anyone interested in > > The usual set. Some outdated, most waiting for stabilizations and > cleanups, some have bugs open. > > -- juippis -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55
[gentoo-dev] Up for grabs: dev-util/lttng and related packages
Hi All: Here is the package list: dev-util/lttng-modules dev-util/lttng-tools dev-util/lttng-ust dev-util/babeltrace I'm not actively using lttng, and these packages really need some love to take care of.. There are some bugs, and lttng-modules may become broken quite easily when compiling against new kernel versions New version bumps are also available -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55
[gentoo-dev] Re: [gentoo-dev-announce] Multiple packages up for grabs (incl. zsh, feh, zathura, qbittorrent)
Hi All On 10:59 Sat 26 Aug , Ionen Wolkens wrote: > Noticed that the following packages have been dropped to m-n > back on August 9 2023, but no mail been sent: > > media-gfx/feh will grab it as I'm using this app but feel free to co-maintain.. -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55
Re: [gentoo-dev] Multiple packages up for grabs (incl. zsh, feh, zathura, qbittorrent)
Hi orbea: On 12:22 Sat 26 Aug , orbea wrote: > On Sat, 26 Aug 2023 10:59:59 -0400 > Ionen Wolkens wrote: > > > Noticed that the following packages have been dropped to m-n > > back on August 9 2023, but no mail been sent: > > > > I can maintain media-gfx/feh and x11-misc/xclip, I maintained feh for > slackbuilds.org for a few years when I was more active there. > Thanks for the interests I'll take care of this, and along with x11-misc/xclip package There is one bug of x11-misc/xclip, will assign to you > Would I just submit a PR to change the maintainer status? So no PR needed -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55
[gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs
Hi All: I will help with the following packages, but if anyone is interested, feel free to join to co-maintain them.. Thanks On 12:01 Wed 03 Apr , Michał Górny wrote: > The following packages are up for grabs due to the inactivity of their > maintainers: > > acct-group/privoxy > acct-user/privoxy > net-proxy/privoxy I occationally use this app, so can take it > media-libs/imlib2 > media-plugins/imlib2_loaders also, some app I used depend on above packages > > -- > Best regards, > Michał Górny > -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55
Re: [gentoo-dev] Packages up for grabs
On 21:08 Sun 23 Nov , Daniel Campbell wrote: > > I'd like to take x11-misc/spacefm if a developer is willing to allow > me to proxy-maint until I become a developer. update metadata.xml, using your email found in bugzie. and current no bug opened, thanks btw, any particular reason why should we keep so many stable versions? probably start doing by cleaning old versions ;-) > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQEcBAEBAgAGBQJUcqEYAAoJEJUrb08JgYgHJ0IIAK+tguKdL+JxdjKLySOSJaTU > kiU1z2rBqUfPzs8VI3V8JAAL9dbSJel4h3/JdoZFpidC9jED63l5STmGXi6dp63O > 9CKqNQRt4AELfOUpQzxoD4HNHVxaA9hkiiJXgAoF9HIfKBEqczPCBKGnJb5s1WB5 > 8eQkn6t6DZMZeRV/dE6pw1RgTj1eHowu2es67V7+bHMiy2ylz5/4ru0dx+1UHvU1 > UeBBcB1IesAVxVsfpBLJoi+aZA9CO9EAriaGogzTXQPP5odr4bgIf5acxOPKGxt0 > iz62j/XgG3jTExqkP5rNaTVnO9ZZol8XPcLiAIZTEl79XU0ZOcy5LDUsJNY+9cI= > =stIL > -END PGP SIGNATURE- -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55
Re: [gentoo-dev] Packages up for grabs
On 22:40 Sun 23 Nov , Alex Xu wrote: > On 23/11/14 08:17 PM, hasufell wrote: > > packages up for grab: > > > > I didn't change metadata.xml, nor bug reports for any of those, because > > I was too lazy. If you grab one, please do so yourself. > > how will bug-wranglers know where to assign packages then? > > > app-misc/trash-cli > > > > co-maintained by games > > games-misc/katawa-shoujo > > games-roguelike/FTL > > > > co-maintained with Lars Wendler > > media-sound/umurmur > > I can proxy these if the relevant people agree. done, update all metadata.xml btw, you should really finish your dev bug, and do this yourself ;-) thanks > -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55
Re: [gentoo-dev] Packages up for grabs
Hello ablepharus I couldn't found your account info (base your email) in bugzilla. also I'd be happy if you can convince me you do have a few experience on ebuilds writing ;-) assume you already familiar with how @proxy-maint goes[1] thanks [1] http://wiki.gentoo.org/wiki/Project:Proxy_Maintainers On 23:49 Tue 25 Nov , ablepharus wrote: > I would like to take care of the following packages but I would need a > proxy-maintainer. > > > hasufell writes: > > app-admin/clustershell > > dev-python/simplegui > > dev-python/jedi > > dev-libs/mathjax > > net-misc/youtube-viewer > > > co-maintained by games > > dev-games/mygui > > games-action/armagetronad > > games-strategy/liquidwar6 > > > > co-maintained with Patrick Lauer > > sci-mathematics/flint > -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55
Re: [gentoo-dev] Retirement / packages up for grabs
Hi All On 22:50 Mon 08 Apr , Austin English wrote: > Howdy all, > > I haven't had much time for Gentoo lately, so I'm turning in my keys. > It's been a great learning experience, and I hope my contributions were > helpful. Best of luck on your future endeavors. > thanks for all your contributions, wish you best! > The following packages are up for grabs: > dev-lang/tcc > dev-util/repo will take these two, but feel free to co-maintain if anyone interested -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55
Re: [gentoo-dev] Packages up for grabs due to cardoe being MIA
Hello It's sad to see cardoe gone .. I wish he will come back someday On 16:44 Fri 13 Sep , Michał Górny wrote: > Hello, > > The following packages are now up for grabs since Undertakers have not > received any reply nor seen any activity from cardoe: > > dev-util/crash [b,v] I'd like to take this one .. but feel free to co-maintain if someone's interested in > > The packages marked [v] have version bump requests open. The packages > marked [b] have other bugs reported. > > -- > Best regards, > Michał Górny > -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55 signature.asc Description: Digital signature
Re: [gentoo-dev] packages up for grabs
On 17:47 Mon 18 Nov , Tim Harder wrote: > The following list of packages are up for grabs that I dropped myself as > as a direct maintainer from. There are probably a significantly larger > number that I've indirectly maintained hiding under the guise of older > projects that mostly act likes herds (e.g. graphics, sound, and vim to > name a few) so interested parties should feel free to directly add > themselves as maintainers for such packages. > > Note that some of the packages in this list already have maintainers, > but I'm sure most of them wouldn't mind co-maintainers. > net-misc/autossh I'd like to take this one as I'm using it daily -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55
Re: [gentoo-dev] arm64
On 20:57 Sat 24 Jan , Tom Gall wrote:
> Hi All,
>
> This is sort of a CFP in some ways but not quite that formal. I’ve been
> throttled back on arm64 for a bit as the hardware I’ve had access to has all
> been painfully remote and configured in ways that was less than optimal for
> massive key wording efforts.
>
> That’s about to change.
>
> So if there are others out there who have the same interest be great to
> coordinate efforts and get this moving along so we have arm64 stages and
> start to pull together install instructions for the varies pieces of hardware
> starting to show up.
>
Hi
I've already keyworded a few ebuilds.. but unfortunately the hardware
I'm using now can't be available for end user
the arm64 profile is still experimental.. massive USEs have been masked [1]
tests/verification are required.
[1] ${PORTDIR}/profiles/arch/arm64/use.mask
--
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55
Re: [gentoo-dev] arm64 update
On 14:27 Wed 18 Feb , Tom Gall wrote: > So first, for those interested in cheap arm64 hardware, the first 96 board is > going to start shipping in March for ~$129. The HiKey board is an 8 way 64 > bit ARM board with 8 A53 cores. (No A57s bummer!) Only had a gig of memory > on the board but it’s not a bad device. I’ve had one for about 2-3 weeks now. > I’m basically running off a USB hard disk for the moment and thankfully the > kernel continues to improve. > > The one downside is you really really need a 1.8v USB -> UART cable. You can > get them from digikey and connect it on the board. If working with raw cables > makes you squeamish take a breath, you’ll be fine. > > Info and links at: > > https://www.96boards.org > > > Ok so hardware aside here’s the arm64 gentoo plan. > > 1) new stage3 put together and get that onto the mirrors for consumption. > 2) Get the handbook extended to include arm64 > 3) continued package stabilization > > Volunteers most welcome. > Hi Tom I'd do step 0) -> keyword ebuilds, and here are the ebuilds [1] which all tested on my hardware here (also A53) xfce4, lxde works here; have problem with qt4, no arm64 support, can leverage patches from debian/ubuntu; btw, is there any script to do massive keyword? [1] http://dev.gentoo.org/~dlan/misc/keyarm64.txt -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55
Re: [gentoo-dev] Packages up for grabs
On 21:13 Tue 21 Apr , Pacho Ramos wrote: > Due to iksaif not having enough time to maintain this, the following package > if up for grabs now: > sys-fs/dfc I can take this, current there is one open bug (version bump) -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55
Re: [gentoo-dev] How to structure our RISC-V support
On 22:30 Thu 06 May , Andreas K. Huettel wrote: > > > > Haven't I told you using two-level libdirs is stupid? So yes, > > please do that and let us be happy once again. > > > > That said, where does lp64gc land? Or isnon-multilib > > one-or-the-other the goal? > > It would be non-multilib one-or-the-other then for us. > The main relevant combination is rv64gc/lp64d, which is arguably what > a linux machine "should have". > > (I could also imagine to keep rv64imac/lp64 profile and stages (also > using lib64), these would have to mask stuff like rust then though.) > I'm fine with rust masked in lp64/other profile.. but in my opinion: it's really up to upstream should fix/support it > (Unless Palmer et al come up with a fix for the libdirs on the > upstream side of things. Already e.g. libdir=lib64-lp64d would be much > easier to handle I suspect.) using one level path (eg. lib64-lp64d) won't fix the problem, the root cause is that we use a 'non-standard' lib path (QT5, Cmake issue), not matter it's one level or two level path, see bug here [1] [1] https://bugs.gentoo.org/781134 https://gitlab.kitware.com/cmake/cmake/-/issues/22138 -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55
Re: [gentoo-dev] How to structure our RISC-V support
On 22:01 Thu 06 May , Andreas K. Huettel wrote:
> Howdy.
>
> I'm sending this not only to the team members on the alias, but also
> to the whole dev list for discussion.
>
> So far I've been trying to support in Gentoo the full risc-v multilib
> directory structure and the ABI sets supported by glibc. According to
> specs this means for riscv64
>
> -mabi=rv64gc -march=lp64d
> libdir = lib64/lp64d
> ("hardfloat")
>
> -mabi=rv64imac -march=lp64
> libdir = lib64/lp64
> ("softfloat")
>
> and theoretically similar for riscv32 (which just landed in glibc and
> is still broken in qemu-user).
>
> However, this leads to several levels of pain (and I definitely dont
> have time to deal with it myself):
>
> a) In many places the two-level libdir (e.g., /usr/lib64/lp64d) leads
> to difficulties in build systems. Right now Qt5 and CMake are still
> somewhat broken (in *Gentoo*).
>
> b) Rust only supports rv64gc/lp64d. (Which is arguably what you should
> have for decent Linux support.)
>
> I'm pretty sure these are not the only things, but they are somewhat
> symptomatic.
>
> So, I would like to bring two proposals up for discussion.
>
> 1) We stop caring about anything except rv64gc/lp64d.
> People can still bootstrap other stuff with crossdev etc, but the
> Gentoo tree and the riscv keyword reflect that things work with above
> -mabi and -march settings.
>
fine by me, for current software/upstream state, it's probably the most
practical way
to only support lp64d, this will significantly ease our life ..
besides, it's relatively easy if people want to support more (lp64/lp32..) later
> 2) We drop the multilib paths and use "normal" lib64, with additional
> "safety symlinks" (/usr)/lib64/lp64d -> .
> This is what SuSE and (I think) Fedora already does. The symlink
> should be there since "lib64" is NOT an official fallback coded into
> gcc/glibc/binutils; the only fallback present is "lib" ...
>
can we use different scheme for non-multilib vs multilib?
1) non-multilibe: just use "normal" lib64, keep align with other ARCHs (amd64)?
2) multilib: just stick to current two level lib path
> --
> Andreas K. Hüttel
> dilfri...@gentoo.org
> Gentoo Linux developer
> (council, toolchain, base-system, perl, libreoffice)
--
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55
Re: [gentoo-dev] [RFC] Plans for a Gentoo/LoongArch port
HI Xuerui: This must be a *HUGE* project and gonna put lots of effort in to it! So, first, good luck to you with all my best wishes!~ On 00:39 Thu 12 Aug , WANG Xuerui wrote: > Hi everyone, > > I'm your average Gentoo user who obviously thought his sleeping time is more > than enough, and just decided to start porting Gentoo to LoongArch. As this > is such a niche architecture with no upstreamed support so far, I'm posting > this to announce my intent and gather advice on how to best push this. > > I'll first give some background material to help people gain context, then > describe my porting plan. This is going to be a bit long; apologizes for > that. > > > Note: I'm not affiliated with Loongson in any way; I'm just doing this in my > spare time (once meant for some quality sleep). > > > ## A bit of introduction on the LoongArch > > LoongArch, as its name implies, is the brand-new ISA developed by the > Loongson Corporation, incompatible with MIPS which was implemented by > all previous Loongson processors. Currently only the base ISA specification > is publicly available; it has fixed-length 32-bit instructions, vastly more > instruction formats (39 distinct formats in the base ISA alone!), and its > instruction semantics mostly resemble RISC-V, with a bit of MIPS R6 here and > there. It is capable of 64-bit operations, obviously. > > ISA documentation: https://github.com/loongson/LoongArch-Documentation > ELF psABI draft: https://github.com/loongson/LoongArch-Documentation/pull/3 > > The draft ABI is undergoing fierce review, and is subject to change, > especially the relocation types. Other parts like the register > convention and > data layout is unlikely to change much, though. > > There is little code upstreamed for basic software (GNU toolchain, QEMU, > Linux and the like), but many are open-sourced already. Nevertheless, the > code quality is still very much inferior, and much of it is obviously based > on respective MIPS support. There is continuous debate inside and outside > Loongson on this matter, too. > Didn't do any investigation, but if I read correctly, also see here [1] The fundamental pieces of softwares are open-sourced but *NOT* yet upstreamed So, I'd say, let's wait till it's actually accepted by upstream, before pushing to downsteam (Gentoo here). Sure, you're free to send a pull-request for review/comment, but collect peices under your own overlay would be a good idea ( in my humble opition ). > Kernel ABI and glibc code seems to be inspired by RISC-V, but still some > parts show MIPS heritage. The kernel bits are being reviewed on the > linux-arch > mailing list. > > All of the projects above can be accessed at https://github.com/loongson. > > Loongson 3A5000 is the first LoongArch CPU; the Lemote A2101 board with this > CPU can be bought in China for ~4000 CNY already. > > > ## Gentoo porting plans > > I'm planning to take ARCH=loongarch for the port; and support the LP64 ABI > first. I'd like to support both LP64 and ILP32 ABIs, but that's not a > priority. > start with LP64 would be good idea, so same as RISC-V here. > The ABI flag might be named "ABI_LOONGARCH" but that's IMO a bit long (pun > semi-intended); ARCH=loong and ABI_LOONG might be better, I'm open to > suggestions. > > Because much of the ABI and even some toolchain internals are going through > VERY fierce debate and rework, obviously the port will remain experimental > for a long time. Some minimal support should get in tree though; doing so > would ease a lot of pain for experimentation. I already hacked my way to > generate working crossdev toolchains, and is halfway towards a rootfs with > working Python (and Portage). I've already independently ported strace, and > plan to do the same to libffi in the coming days which would give me Python. > > I'll do all work in my own loongson-overlay first, and upstream these when > appropriate. Eventually I hope to have working crossdev, qemu-user emulation > and proper catalyst support. > > sounds a good plan, first start with making cross compiling work, then try to populate a mini rootfs (kernel, glibc, base system), then python, portage > And that's about all; the message is getting long! Your opinions are > welcome, > and thanks again for following along. > > [1] https://github.com/gentoo/portage/pull/740#issuecomment-895021854 -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55
[gentoo-dev] Package up for grabs: net-misc/you-get
Hi, I'm not really actively using it anymore, and sometimes have difficulty to test, I'd appreciate if someone interested and would like to maintain .. There are two open bugs 1) test failure 2) python dep bump also one version bump (see PR 38585) https://github.com/gentoo/gentoo/pull/38585 -- Yixun Lan (dlan)
