Re: [gentoo-dev] Importance of SLOTs on Java dependencies
Chewi suggested a similar solution in #gentoo-java. How do we get started with contributing to repoman? However.. everytime I tried asking questions about repoman, I've been told I shouldn't bother improving it because this magic python script that seems to be doing all sort of things (over 3000 lines packed in one file) (yes my dear) is being rewritten. Is it still underway? Cheers Tuesday 07 Apr 2015 20:41:05, Pacho Ramos wrote : > El dom, 05-04-2015 a las 17:16 +0100, James Le Cuirot escribió: > > Hello all, > > > > Firstly, I would like to take this opportunity to remind all devs > > touching ebuilds with Java .jar dependencies about the importance of > > restricting these dependencies to specific SLOTs. > > > > There is no cross-platform or even platform-specific location for > > Java .jar files so each distro tends to do its own thing. Gentoo's Java > > eclasses install metadata about any .jar files in a file called > > package.env either at /usr/share/${PN}-${SLOT} or just /usr/share/${PN} > > when the SLOT is 0. > > > > java-config is executed both at build time and at run time to read this > > metadata so that it can build a classpath. If one of the dependencies > > unexpectedly changes SLOT due to package updates then the chain breaks. > > You must therefore *always* restrict the SLOT, even if that dependency > > currently has a SLOT of 0. > > > > Why do we SLOT Java stuff so much? Java applications tend to have many > > third party dependencies so it is inevitable that we would sometimes > > need to have more than one version of a library installed at one time. > > The write once, run anywhere nature of Java also means that upstream > > doesn't expect you to run against library versions other than the ones > > they shipped their application with. We do have a tool to check for > > compatibility between versions though to avoid SLOT proliferation > > getting out of hand. Classpath conflicts involving multiple versions > > have rarely been an issue up till now but we have thought of measures > > to combat this in future if needs be. > > > > I felt the need to write the above because I have seen many instances > > where devs not familiar with Java packaging have made this mistake. Now > > I need to ask what to do in the case of ebuilds that have already been > > marked stable. > > > > To bring up a real example, I would like to bump dev-java/jna with a > > new SLOT for the new version. There are several reverse dependencies, 3 > > of which do not specify a SLOT, and 2 of these have already been marked > > stable. Upon giving jna a new SLOT, all these packages would instantly > > fail to build if jna:0 is not already installed and they would also > > fail to run if jna:0 gets depcleaned. Simply leaving the stable ebuilds > > as they are is therefore not an option. My preferred solution would be > > create a revbump that solely amends (R)DEPEND, leaving the KEYWORDS > > exactly as they are. This is controversial but what other choice is > > there? I could delay the jna bump but this would push back this thread > > of work by a month when I already have a huge backlog. Please do not let > > bureaucracy get in the way here. > > > > Of course I would certainly give any maintainers a heads up before > > doing this. Unfortunately, in this particular case, I contacted miknix > > about dev-embedded/arduino over 2 weeks ago and haven't heard anything > > back. He hasn't been seen on IRC for over 5 months. :( > > > > Wouldn't be possible to show a repoman warning when a dependency on any > dev-java/${PN} doesn't specify a SLOT? That would save of from > forgetting this in some years ;) > >
Re: [gentoo-dev] Becoming a Gentoo developer?
Monday 13 Apr 2015 03:27:19, Daniel Campbell wrote : > On 04/12/2015 05:17 AM, Yanestra wrote: > > Hi, > > > > I am long time user of Gentoo and I tinker with the idea of becoming > > Gentoo developer. > > > > I am a software developer by profession, but I am not quite sure if I > > should involve with Gentoo ebuild development. > > > > To be honest, I have not the slightest imagination what becoming a > > Gentoo developer might mean. Things seem to be abhorringly complicated. > > > > As far as I understand, there are developers, proxy developers, then > > there is something like Project Sunrise which I don't understand. > > > > There are apparently several different portage source repositories, > > basing on different software, and furthermore, there is layman. As far > > as I remember, portage is stored in cvs, where there is also git, and > > somewhere subversion seems to linger. > > > > And there is lots of documentation that appears to be outdated or > > strangely unattached to questions concerning organisation and overall > > structure. > > > > Can someone please tell me where to start becoming a developer? Do there > > exist something like quality guidelines for ebuilds? > > > > Why is there such a chaos? > > > > Thanks! > > > > As someone who is undergoing their IRC interview soon, I think I can > answer some of these questions: > > * There are developers, proxy-maintainers, and the Sunrise project. > Developers have access to the main Gentoo repository of ebuilds and do > their best to maintain a quality tree. Proxy-maintainers are regular > Gentoo users who "adopt" packages and pledge to help Gentoo developers > in maintaining them until either they become a developer themselves or > until another developer adopts the package officially. The Sunrise > project is a separate tree where developers and users collaborate in > getting new or specialized packages into a semi-official repository. > Developers assist users in getting ebuilds up to snuff and help them > build practical skills in contributing to Gentoo in a more structured > manner. > > * Documentation, like the rest of Gentoo, is powered by volunteers. If > you find any missing, erroneous, or outdated information, please file a > bug or, if you have permissions on the Wiki, edit it yourself! > > * The general structure of Gentoo as an organization is somewhat simple. > The Council makes all the big and important decisions, while developers > have their own "herds" for specific goals (say, the perl, lisp, java, > and games herds), which also correspond to projects with the same goals. > The Foundation exists to give Gentoo adequate monetary and legal support > in carrying out its goals as a distribution. Everything else is pretty > much just a bunch of developers working together. > > * Gentoo's official tree is in CVS for now, but there is a git migration > planned. I don't know the timing or exact plans for the immediate > future, but my guess is things will be switching to git over the long > term once logistic problems are solved. SVN repositories are available > over layman only, as far as I'm aware. > > * Layman itself is a way to activate other repositories. That method is > partially deprecated in favor of /etc/repos.conf/ files, which allow for > greater, clearer control over repositories. Current releases of layman > will interface with the new way of managing, and there are tools in > place to make migration (mostly) painless. > > * The way to begin your journey to become a developer lies mostly in > just helping out Gentoo, studying the Devmanual [0], and contacting > recruiters to see if there is a mentor available for you. > > If you're interested in becoming an ebuild developer, you should try out > the ebuild quiz [1]. For the most part it just takes a cautious and > attentive eye, some adequate knowledge of bash, and familiarity with > common building and admin tools. Since you're a developer by trade, I'm > sure it wouldn't be a big problem for you to reach developer status. It > takes time and effort, but in my personal opinion it's been worth every > moment. > > I hope this helps! > > ~Daniel > > [0] https://devmanual.gentoo.org > [1] https://wwwold.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt > Hi Yanestra Daniel summed it up pretty well: becoming a dev is a long and lengthy process but worth it in the end cause you'll get to meet smart and passionate folks along the path. However, I'd like to point out yet another URL nobody has mentioned so far: bugzilla [2] aka the Gentoo bug tracking system. There are always tons of bugs waiting to get picked up. You're a software developer by profession so I would advise you to look for bugs that lie in your field of interest. Gentoo isn't one "big" aggregate of developers. We're broken down into small teams of people working on a specific topic. You can check out the list of "Projects" here [3]. For instance do you like Perl? Help out the Perl team packag
Re: [gentoo-dev] Becoming a Gentoo developer?
If, by any chance, you happen to like Java, we're looking for fresh blood. We're kinda short of manpower in the team at the moment: with over 1000 bugs assigned to java@g.o, any form of help is welcome. Further, you'll get to work on maintaining some of Chewi's ebuilds, some of which encompass Minecraft. (you might wonder: who's interested in playing Minecraft on Gentoo? I asked myself the same question till I bumped into Chewi..) Patrice Monday 13 Apr 2015 14:20:56, Patrice Clement wrote : > Monday 13 Apr 2015 03:27:19, Daniel Campbell wrote : > > On 04/12/2015 05:17 AM, Yanestra wrote: > > > Hi, > > > > > > I am long time user of Gentoo and I tinker with the idea of becoming > > > Gentoo developer. > > > > > > I am a software developer by profession, but I am not quite sure if I > > > should involve with Gentoo ebuild development. > > > > > > To be honest, I have not the slightest imagination what becoming a > > > Gentoo developer might mean. Things seem to be abhorringly complicated. > > > > > > As far as I understand, there are developers, proxy developers, then > > > there is something like Project Sunrise which I don't understand. > > > > > > There are apparently several different portage source repositories, > > > basing on different software, and furthermore, there is layman. As far > > > as I remember, portage is stored in cvs, where there is also git, and > > > somewhere subversion seems to linger. > > > > > > And there is lots of documentation that appears to be outdated or > > > strangely unattached to questions concerning organisation and overall > > > structure. > > > > > > Can someone please tell me where to start becoming a developer? Do there > > > exist something like quality guidelines for ebuilds? > > > > > > Why is there such a chaos? > > > > > > Thanks! > > > > > > > As someone who is undergoing their IRC interview soon, I think I can > > answer some of these questions: > > > > * There are developers, proxy-maintainers, and the Sunrise project. > > Developers have access to the main Gentoo repository of ebuilds and do > > their best to maintain a quality tree. Proxy-maintainers are regular > > Gentoo users who "adopt" packages and pledge to help Gentoo developers > > in maintaining them until either they become a developer themselves or > > until another developer adopts the package officially. The Sunrise > > project is a separate tree where developers and users collaborate in > > getting new or specialized packages into a semi-official repository. > > Developers assist users in getting ebuilds up to snuff and help them > > build practical skills in contributing to Gentoo in a more structured > > manner. > > > > * Documentation, like the rest of Gentoo, is powered by volunteers. If > > you find any missing, erroneous, or outdated information, please file a > > bug or, if you have permissions on the Wiki, edit it yourself! > > > > * The general structure of Gentoo as an organization is somewhat simple. > > The Council makes all the big and important decisions, while developers > > have their own "herds" for specific goals (say, the perl, lisp, java, > > and games herds), which also correspond to projects with the same goals. > > The Foundation exists to give Gentoo adequate monetary and legal support > > in carrying out its goals as a distribution. Everything else is pretty > > much just a bunch of developers working together. > > > > * Gentoo's official tree is in CVS for now, but there is a git migration > > planned. I don't know the timing or exact plans for the immediate > > future, but my guess is things will be switching to git over the long > > term once logistic problems are solved. SVN repositories are available > > over layman only, as far as I'm aware. > > > > * Layman itself is a way to activate other repositories. That method is > > partially deprecated in favor of /etc/repos.conf/ files, which allow for > > greater, clearer control over repositories. Current releases of layman > > will interface with the new way of managing, and there are tools in > > place to make migration (mostly) painless. > > > > * The way to begin your journey to become a developer lies mostly in > > just helping out Gentoo, studying the Devmanual [0], and contacting > > recruiters to see if there is a mentor available for you. > > > > If you're interested in be
[gentoo-dev] [gentoo-dev-announce] Last rites: dev-java/openjms
# Patrice Clement (14 Apr 2014) # Upstream seems to be dead. No updates since 12 March 2007. # Masked for removal in 30 days. See bug 546506. dev-java/openjms pgpoUgIhksvEx.pgp Description: PGP signature
[gentoo-dev] [gentoo-dev-announce] Last rites: dev-java/xt
# Patrice Clement pgpWovcCCDB1E.pgp Description: PGP signature
Re: [gentoo-dev] more packages up for grabs
Monday 18 May 2015 17:13:41, Tim Harder wrote : > Here are some packages that I've dropped (or will drop) myself as > primary maintainer from. Many of them (e.g. protobuf*) could really use > some more collaborative non-maintainer update method but no one has > gotten around to finalizing, documenting, and implementing the required > metadata.xml changes yet as far as I know. > > * app-misc/pfm > * www-client/links > * www-misc/urlwatch > > If you have questions about any of them feel free to drop me a line. > > Thanks, > Tim Hey Tim I'd love to pick these up. In particular links: always been fond of it. :) Cheers, Patrice pgp3G_Kfuhleh.pgp Description: PGP signature
[gentoo-dev] [gentoo-dev-announce] Last rites: dev-java/excalibur-logger
# Patrice Clement (25 May 2015) # Upstream dead. Project no longer supported by the ASF # who moved it into the Attic in 2010. # See #550326. Masked for removal in 30 days. dev-java/excalibur-logger pgphGZTVlwCAX.pgp Description: PGP signature
Re: [gentoo-dev] RFC: ban EAPI 1
Wednesday 10 Jun 2015 22:43:10, Ulrich Mueller wrote : > Hi, > The number of EAPI 1 ebuilds in the Portage tree has decreased to > a total of 60, corresponding to 0.16 %. > > We briefly discussed in the QA team if we should demote EAPI 1 in > layout.conf from "eapis-deprecated" to "eapis-banned". This would > have the consequence that repoman would refuse to commit packages > containing such ebuilds. AFAICS there would be no impact on users. > > What do you think? > > Ulrich Make it happen! pgpXWxYvFmO0B.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-java/aspectwerkz
# Patrice Clement (14 Jun 2015) # Upstream dead. No update since 2005. # Masked for removal in 30 days. dev-java/aspectwerkz pgp_VbFm_2dK4.pgp Description: PGP signature
Re: [gentoo-dev] A few mgorny/ projects for upstream-grabs
Hi Michal I could help out with phsh if you need a hand. Cheers, Patrice Monday 15 Jun 2015 19:54:59, Michal Górny wrote : > Hi, everyone. > > My time for Gentoo is quite limited right now (you gotta start working > for money at some point :)), and the little time I have I'm trying to > use for the Gentoo work I consider most important. This sadly means > that many of my past tools are earning their share of bitrot and would > really use a new contributors, or possibly even full-time upstream > maintainers :). > > Here's a long list of projects along with short description, their state > and planned TODO items that I won't have time to implement anytime soon. > > > app-admin/eclean-kernel > > The tool to clean up old kernels. A bit controversial in the end > because /boot is a mess. > > status: works with some /boot layouts, fails hard on some, has some > known bugs/requests > > TODO: > - figure out how it sanely could work, > - support /boot shared between multiple systems, > - support BootloaderSpec (maybe), > - clean up the code, possibly rewrite in something saner than Python > (C++?). > > > app-cdr/mirage2iso > > Quite an old tool to convert various image formats to .iso using > libMirage. > > status: working, no known bugs, may use a little cleanup > > TODO: > - support selecting track to read (right now it reads first supported > one), > - support extracting multiple tracks (sessions) -- options to pass > track list and output filename pattern, > - support converting to .bin + .toc/.cue, > - support for more track types (right now, Mode 1 & Mode 2 form 1 are > supported), > - support for audio tracks (how? external converter? a library?). > > > app-portage/cpuinfo2cpuflags > > The tool to get CPU_FLAGS_X86 for your system :). Not really > abandoned but I have some TODO items I won't be able to do soon. > > status: working, no known bugs > > TODO: > - replace /proc/cpuinfo parsing with CPUID assembly/intrinsics -- > support more kernels than just Linux, > - possibly extend to non-x86 arches. > > > app-portage/diffmask > > A tool to maintain package group unmasks in sync, and clean up stale > unmasks. Quite specific since it requires unmasks to be copied > exactly from mask file. > > status: quite working, not exactly proud of the design > > No real TODO items but it would be nice to think a bit about > the design and figure out if we couldn't do something more user- > friendly (i.e. not being that strictly bound to package.mask). > > > app-portage/flaggie > > The package.use (& make.conf) flag management tool. Pretty high > priority. > > status: rather working, has a few bugs, certainly would use some new > Portage features > > TODO: > - remove make.conf editing support (it's very complex and broken -- > can eat random '$' from the file in some cases), > - therefore: edit global flags via '*/*' entries in package.use, > - support writing 'FOO_BAR:' format for USE_EXPAND in package.use, > - support parsing 'FOO_BAR:' format for USE_EXPAND on command-line > (i.e. 'flaggie libfoo VIDEO_CARDS: +radeon -nvidia'), > - remove implicit '*' expansion in package names and flag names -- > package.use can handle '*', so leave it as is and just expand it > when checking if the flags are supported, > - possibly clean up package.use writer (or rewrite it since I'm > no longer able to figure out how it works exactly :)). > > > app-portage/gentoopm > > A wrapper providing nice API to all three Package Managers. Used by > gpyutils, smart-live-rebuild... > > status: stuck in EAPI 4 era, might have some hidden bugs > > TODO: > - add APIs for EAPI 5 -- but this requires Package Manager APIs first, > - maybe some cleanup. > > > app-portage/install-mask > > A tool to update INSTALL_MASK in make.conf using well-known file > groups. Uses make.conf manipulation code from flaggie. > > status: working, make.conf manipulation broken as in flaggie > > TODO: > - the tool should be killed, and INSTALL_MASK group support should be > moved into Portage :). Alike: > > INSTALL_MASK="@systemd @locale -@locale_pl" > > with matches being applied sequentially, and groups being defined > in $repo/metadata/install-mask.conf [and masters]. > > > app-portage/pms-test-suite > > A GSoC project and as such, totally abandoned. Not sure if anybody > really cares these days. > > status: stuck in EAPI 4 era, waiting for EAPI 5 in gentoopm... > > TODO: > - support EAPI 5, > - find some use for it? > > > dev-util/atomic-install > > A nice one -- tool to quasi-atomically install files from $D to live > system. The idea is to replace live files as fast as possible, > and quickly revert that if it fails in the middle. Never finished but > nevertheless a good idea :). If someone's up for it, I'd love to see > it working one da
[gentoo-dev] Last rites: dev-java/mockmaker
# Patrice Clement (22 Jun 2015) # No update from upstream since 2002. This package might cause problems with # new JDKs. Removal in 30 days. dev-java/mockmaker pgpkfuNinZ4VQ.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog kde5-functions.eclass kde5.eclass
man 3 glob man 3 fnmatch man 1 bash -> read the section called "Pattern Matching" under "EXPANSION". in this case, $(ls) would unnecessarily spawn a subshell for listing files. You can often get the same result by using wildcard expansion (or globbing) like Michal said: for lang in *; do ... done It is often faster. Cheers, Patrice Sunday 28 Jun 2015 14:25:25, Johannes Huber wrote : > On Sunday 28 June 2015 04:12:01 Michal Górny wrote: > > > > + for lang in $(ls) ; do > > > > How about... for lang in *? > > What is the advantage? > > Greetings > -- > Johannes Huber (johu) > Gentoo Linux Developer / KDE Team > GPG Key ID FDF4F788 pgpz97nHdicW7.pgp Description: PGP signature
Re: [gentoo-dev] Git workflow
Sunday 05 Jul 2015 16:03:27, hasufell wrote : > On 07/05/2015 06:10 AM, C Bergström wrote: > >>> 5) More about linear commits and "history" - I need to double check, > >>> but I don't think rebase changes the actual commit date (I could be > >>> mistaken). > >> > >> You are mistaken, and should have double checked before you argued. > >> > >> Arguing without checking makes you look bad. > > > > How? I didn't claim to know and clearly not knowing didn't seem > > important (to me). I'm not trying to overstate anything. I'm just > > trying to passionately bring this up. I ***wish*** someone with some > > guts would actually take charge of this on the gentoo side, have a > > vote or make some executive decision which is stronger than this wimpy > > policy we have now. > > > > Most of what you brought up wasn't really useful critique, but rather > noise based on your personal frustration with git. > > This thread is not about giving lectures on how git works. We appreciate > useful comments on the git workflow. But in order to give useful > comments, you have to know and understand the project and how it works > internally. > > There will be a sh*tload of developer, feature and whatnot branches. It > is just insane to tell everyone to unconditionally do rebases > everywhere. You haven't even commented on a fraction of the resulting > problems. So please lets stop this discussion and move on. > +1 How about you guys carry on this discussion somewhere else in a place like, I don't know, IRC? #which-git-workflow-fits-best-my-needs
[gentoo-dev] Last rites: app-arch/dczip net-p2p/frostwire
# Patrice Clement (5 Jul 2015) # SRC_URI unreachable. Upstream looks dead. # Removal in 30 days. See bug #502994. app-arch/dczip # Patrice Clement (5 Jul 2015) # Package does not compile with recent JDKs (>= jdk-1.8). More recent versions # use Gradle which we don't have packaged in Gentoo yet. # Removal in 30 days. See bug #552452. net-p2p/frostwire pgpQ99CJ4o3g7.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Rebooting the Installer Project
Saturday 18 Jul 2015 15:36:01, NP-Hardass wrote : > On Sat, 18 Jul 2015 12:01:48 -0700 > Matthew Marchese wrote: > > > Hello all, > > > > I have recently pressed the reboot button on the ol' Installer > > project. I've been able to talk to quite a few developers one-on-one > > via IRC concerning my plans. Most seem to be in support of Gentoo > > having a "official" installer (the biggest concern is appears to be > > how things will be implemented and the amount of features involved). > > This e-mail is to fulfill GLEP 39's request for comments (RFC), > > concerns, requests, etc. Since I'm a little new to the project I'm > > coming with a bit of ignorance; I know the previous Installer project > > fostered mixed feelings. > > > > If you'd like to review before replying you can see the Wiki page and > > find the source on GitHub: https://github.com/gentoo/stager > > > > To summarize I'm writing it in pure Python 3. It first will be able > > to create full backups (stage 4s) and recoveries. After that is > > finished I plan to move on to installations. There will potentially > > be a web interface UI for it. Others are free to create other > > front-ends; to me a web UI makes the most sense and would probably > > require the least deps. > > > > I'd like to hear it all so please speak your mind. Looking forward to > > hearing from you. > > > > maffblaster > > Hi Matthew I fancy your idea a lot. We ought to do it for complete newbies who are new to Gentoo but would like to give the distribution a shot nonetheless. I fondly remember my first attempt who took me ages to complete.. Good times. :) Following up on NP-Hardass' email in which he's raising good points: > Who is your target audience? New users? Experienced users? Not so > much a comment about your installer, but installers in general, I feel > the handbook is critically important to helping new users to understand > Gentoo. Whether the handbook would remain a resource that users would > look at if they had an installer remains to be seen. IMHO, users should be guided and walked through the installation process. They should understand what's going on so the Handbook must be equally important as when a normal chap installs Gentoo without using the installer. It should ask users trivial questions, a bit like the Debian CLI installer. "Which partition do you want to format?" "How do you want to configure your network interface?" etc. Worth mentioning for sysadmins, devops and users alike: automation is all the rage these days. Beyond creating an installer, it'd be interesting to feed the program with a sort of "configuration file" so that the whole process can be performed in one go. Or think about integrating it with Chef, Puppet et al. I think it's a personal taste here and whether we want to reinvent the wheel or not. > The project page > states: > > "Greatly aiding the "fresh install process". stager will not > remove the need for reading through the Handbooks, but rather work > along side the handbook in order to help users install Gentoo." > > Can you elaborate on this? I have trouble envisioning an automated > installer process that requires working along side the handbook. > > I know that you mentioned a web interface. I assume that you there are > plans for a simpler, local interface like ncurses or cli, or text in a > terminal? Is it meant to be interactive? Python has an ncurses module that allows developers to create interactive programs out of the box. The web interface would also be a interesting feature (maybe for remote installations?) but truth to be told, I see it as a "nice to have" feature rather than a "must have". > I like the idea of having an automated installer, so I wish you the > best of luck with the project. I'm sure you'll encounter tons of > people with tons of opinions on what it should and shouldn't be, so > just do your best to maintain a clear, well-defined vision and stick to > it. > Definitely. Write a roadmap and stick to it. Cheers, Patrice pgpbM4b8TosrW.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-java/jjtraveler
# Patrice Clement (30 Jul 2015) # Broken and upstream dead isn't always a good mix. # Removal in 30 days. See bug #368049. dev-java/jjtraveler
[gentoo-dev] Last rites: www-servers/skunkweb
# Patrice Clement (3 Aug 2015) # Broken and no releases in 10 years (!). # Removal in 30 days. See bug #451790. www-servers/skunkweb
Re: [gentoo-dev] Git workflow, commit messages
Sunday 09 Aug 2015 20:17:57, Patrick Lauer wrote : > On Sunday 09 August 2015 08:06:53 Anthony G. Basile wrote: > > Hi everyone, > > > > I hate to be a nag, but please read > > https://wiki.gentoo.org/wiki/Gentoo_git_workflow. In particular, commit > > messages. I'm seeing lots of cvs style messages going in and without > > history it will be hard to figure out what happened just from the > > message. Particularly, we should prepend "CATEGORY/PN: " to the first > > line so we can easily search git log for what happened to a package. > > Lazy me says: > > Can't we make repoman do that? > We should delegate this task to git and set up a hook for this kind of checks. http://git-scm.com/docs/githooks I'm not going to copy and paste what's on the website but a hook is basically a script that gets executed post/pre commits/push/[insert action here]. Hooks can be written in any programming language. If we take the concept event further, even repoman itself could go away..
Re: [gentoo-dev] git commit / push signing error
Monday 10 Aug 2015 12:02:25, Daniel Campbell (zlg) wrote : > On 08/10/2015 06:15 AM, Doug Goldstein wrote: > > On Mon, Aug 10, 2015 at 3:36 AM, Chí-Thanh Christopher Nguyễn > > wrote: > >> Doug Goldstein schrieb: > >>> gpg: cancelled by user gpg: skipped "0xA2BC03DC87ED1BD4": > >>> Operation cancelled gpg: signing failed: Operation cancelled > >>> error: gpg failed to sign the data > >> > >> There was an IRC discussion yesterday about this. Probably your > >> pinentry tries to talk to a GUI and fails. Try: > >> > >> unset DISPLAY export GPG_TTY=$(tty) > >> > >> to make it fall back to curses, or use "eselect pinentry" to > >> select curses as default. > >> > >> Interestingly, git requires GPG_TTY if eselect-pinentry is set to > >> gtk-2 or qt4, but repoman doesn't. > >> > >> > >> Best regards, Chí-Thanh Christopher Nguyễn > >> > >> > > > > $ eselect pinentry show Current pinentry binary implementation: > > pinentry-curses > > > > $ eselect pinentry list Available pinentry binary implementations: > > [1] pinentry-curses * > > > > Its the only version I've got on this machine. The box is headless > > and I ssh into and I use keychain to manage my SSH and GPG agent. > > > What's your keychain line look like in your .bashrc/.bash_profile? > Here's the relevant portion of mine. I was also having problems with > it until I changed the order of the arguments: > > [snip] > /usr/bin/keychain --agents ssh,gpg ~/.ssh/id_rsa ${GPGKEY} > source ~/.keychain/sporkbox-sh > /dev/null > source ~/.keychain/sporkbox-sh-gpg > /dev/null > [snip] > > For some reason, it's important that ssh comes before gpg. I got this > advice straight from drobbins, so unless it's changed, that's the way > to get it working. > -- > Daniel Campbell - Gentoo Developer > OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net > fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 Would someone mind documenting this issue in the wiki? https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Issues So that we all have a point of reference to go to. Thanks! pgp5LAuSmShMi.pgp Description: PGP signature
[gentoo-dev] Developer branches on proj/gentoo
Hi there According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, "there may be developer-specific, task-specific, project-specific branches etc". As far as I understand, it means I can go and create my own branch on the main repository and push it and it gets spread all over the place. Is that correct? Could someone explain to me the rationale behind this decision? Truth to be told, I kinda dislike the fact any developer can do this. proj/gentoo should be kept for "serious business" i.e. commits that affects the tree. On the long run, if everybody goes down that road, we will see flourish numerous branches (who said unmaintained?), all stalled at a different state of the main repo, and it will only generate a lot of noise and confusion for nothing. Further, since we've moved over to git, the main tree now gets replicated to github and we all have github accounts here, don't we? Which makes the whole forking and submitting PRs a cinch. If a developer wants to tinker with the tree, he can fork it to its github devspace, fiddle around, and later on send us a PR back with his changes to merge. Cheers, Patrice
[gentoo-dev] Last rites: dev-java/{a lot of packages}
# Patrice Clement (19 Aug 2015) # Upstream dead: no releases since 2010. # Technology has moved on and there are far better alternatives # (easymock, mockito and jmock). # Masked for removal in 30 days. See bug #190307. dev-java/mockobjects # Patrice Clement (19 Aug 2015) # Upstream dead too: no releases since 2005. # Masked for removal in 30 days. See bug #190307. dev-java/xdoclet # Patrice Clement (16 Aug 2015) # Dependency of dev-java/base64. This project isn't getting a lot of traction # and we already have a ton of Java serialiser APIs in the tree. # Masked for removal. See bug #557866. dev-java/java-xmlbuilder # Patrice Clement (16 Aug 2015) # Last release was in 2008. Does not compile with recent JDKs (>= 1.8). # Masked for removal. See bug #557920. dev-java/httpunit # Patrice Clement (16 Aug 2015) # Project discontinued: part of the java.util namespace as of Java 8. # See https://docs.oracle.com/javase/8/docs/api/java/util/Base64.html. # Masked for removal. See bug #557866. dev-java/base64 # Patrice Clement (14 Aug 2015) # Unreachable HOMEPAGE (dead). Very very very old package: # last release came out in 2001. # Masked for removal in 30 days. See bug #232666. dev-java/tclib # Patrice Clement (14 Aug 2015) # Last release is over 13 years old (!). # Masked for removal in 30 days. See bug #177032. app-text/jdictionary # Patrice Clement (1 Aug 2015) # Package relying on j2me. Not useful anymore since j2me has long been removed. # Removal in 30 days. See bug #556460. dev-java/antenna signature.asc Description: PGP signature
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-08-30 23:59 UTC
Thursday 03 Sep 2015 18:01:55, James Le Cuirot wrote : > On Thu, 3 Sep 2015 18:49:05 +0200 > Róbert Čerňanský wrote: > > > Can it be *please* modified so that one removal/addition fits on a > > single line? It is very hard to eye-parse when lines are split in > > two. Or maybe leave the length as is and do not break the lines? > > I agree but it's because it used to just have the CVS username rather > than the full name and e-mail address. I'd be happy with just the > e-mail address. If that's still too long, maybe we could replace > @gentoo.org with @g.o and that would deal with most cases. > > -- > James Le Cuirot (chewi) > Gentoo Linux Developer > Can we also get the SHA1 of each commit/removal? Thanks! -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-08-30 23:59 UTC
Friday 04 Sep 2015 09:59:07, James Le Cuirot wrote : > On Fri, 4 Sep 2015 09:53:38 +0100 > malc wrote: > > > James - you're right - I hadn't paid attention to MTA wrapping... > > Patrice - even though it's counter to what James asked, I added short > > sha-1s [ i.e. the output of git rev-parse --short > > f1cb2b98f62fa9cbf1ef5a0f149dd47fee6964be ] > > Now the output looks like below (or attached txt file) > > That looks very nice, thanks. I don't know what will happen if > something doesn't fit but hopefully it's something sensible. :) > > -- > James Le Cuirot (chewi) > Gentoo Linux Developer > +1 It looks nice indeed. Thanks. @infra: do you guys have a public git repo hosted under http://github.com/gentoo ? -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
Re: [gentoo-dev] symlinks in the tree
Saturday 12 Sep 2015 15:30:45, Justin Lecher (jlec) wrote : > On 12/09/15 15:19, hasufell wrote: > > +1 for banning symlinks > > > > mrueg just mentioned a very crucial point. There are filesystem which > don't support symlinks and would break everything. > > +1 too A functionality that causes a maintenance burden should be avoided. It's just common sense. -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] ALLARCHES and the maintainer action(s)
Saturday 19 Sep 2015 09:55:14, Anthony G. Basile wrote : > On 9/19/15 8:56 AM, Ian Stakenvicius wrote: > > Sent from an iPhone, sorry for the HTML... > > > > On Sep 19, 2015, at 8:31 AM, Vadim A. Misbakh-Soloviov > > wrote: > > > >>> So, if an arch developer tests the package(s) on one architecture, he is > >>> allowed to stabilize/keyword for all. > >> And how about the > >>> some arches rquires additional tests during stabilization, like so: mips*, > >> arm*, and some more exotic ones > >> definition in developer manuals? :) > >> > >> -- > >> Best regards, > >> mva > > The ALLARCHES keyword is meant for stuff that is essentially > > platform-agnostic. Python code shouldn't act any different on arm than > > arm64 than amd64. Using that keyword on something like ffmpeg would be a > > bad use of the keyword. > > Even with python where, for example, `import ctypes' might trigger > something on one arch and not another. Anyhow, thanks for the reminder > ago. I see that keyword as "risky" but an unfortunate risk we have to > take because we are short of manpower and don't have automated arch > testing. I say use it where it appears reasonable (eg interpreted > script and not compiled code) but be ready that every once in a while > we'll get bitten. > > -- > Anthony G. Basile, Ph.D. > Gentoo Linux Developer [Hardened] > E-Mail: bluen...@gentoo.org > GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA > GnuPG ID : F52D4BBA > > We've been using this keyword fairly often (we = Gentoo Java team) whenever possible since the announcement and it worked out pretty well so far. -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
[gentoo-dev] Last rites: dev-java/xmlc + dev-db/derby
# Patrice Clement (1 Oct 2015) # Project is over 10 years old and seems to have stalled. # Masked for removal in 30 days. See bug 561954. dev-java/xmlc # Patrice Clement (24 Sep 2015) # This package was never marked stable # and is relying on an old version of JavaCC. # Masked for removal in 30 days. See bug 561410. dev-db/derby signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-java/bcprov/
Friday 09 Oct 2015 08:28:06, Michał Górny wrote : > Dnia 2015-10-08, o godz. 22:11:12 > "Patrice Clement" napisał(a): > > > commit: 82be4dfc08bacbac9814583a840bb1d2fd59 > > Author: Patrice Clement gentoo org> > > AuthorDate: Thu Oct 8 22:02:48 2015 + > > Commit: Patrice Clement gentoo org> > > CommitDate: Thu Oct 8 22:06:19 2015 + > > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=82be4dfc > > > > dev-java/bcprov: Clean up old. > > > > Package-Manager: portage-2.2.20.1 > > Signed-off-by: Patrice Clement gentoo.org> > > > > dev-java/bcprov/Manifest | 3 -- > > dev-java/bcprov/bcprov-1.38-r2.ebuild | 57 > > dev-java/bcprov/bcprov-1.38-r3.ebuild | 57 > > dev-java/bcprov/bcprov-1.40-r1.ebuild | 59 > > dev-java/bcprov/bcprov-1.45-r1.ebuild | 59 > > dev-java/bcprov/bcprov-1.45.ebuild| 59 > > dev-java/bcprov/bcprov-1.48-r1.ebuild | 64 -- > > dev-java/bcprov/bcprov-1.49-r2.ebuild | 81 > > - > > dev-java/bcprov/bcprov-1.49-r3.ebuild | 81 > > - > > dev-java/bcprov/bcprov-1.50-r1.ebuild | 58 > > dev-java/bcprov/bcprov-1.50.ebuild| 81 > > - > > dev-java/bcprov/bcprov-1.52.ebuild| 84 > > --- > > 12 files changed, 743 deletions(-) > > Replying to one of the particularly influential commits in long batch > of wrongdoing. > > So here you remove all of the ebuild which have SLOT="0", effectively > breaking *stable* dev-java/bcmail, dev-java/bcpkix, dev-java/itext: > > https://qa-reports.gentoo.org/output/gentoo-ci/62d6c0c/6.html#l59 > https://qa-reports.gentoo.org/output/gentoo-ci/62d6c0c/6.html#l153 > https://qa-reports.gentoo.org/output/gentoo-ci/62d6c0c/6.html#l249 > https://qa-reports.gentoo.org/output/gentoo-ci/62d6c0c/6.html#l343 > https://qa-reports.gentoo.org/output/gentoo-ci/62d6c0c/6.html#l710 > > What's even worse, you instantly stabilize new dev-java/bcmail ebuilds > which have the same issue. > > As a side issue, why the hell do you stabilize a number of random old > versions? This does not like a sane solution, instantly adding dozen > of poorly-tested middle versions into the stable tree. > > -- > Best regards, > Michał Górny > <http://dev.gentoo.org/~mgorny/> bcprov ebuilds were a clusterfuck that I was trying to fix and obviously I failed. Taking a look at it right now. Fix underway. -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-java/castor dev-db/octopus
# Patrice Clement (29 Oct 2015) # Upstream is somewhat alive but there are better XML parsers out there. # Removal in 30 days. See #268619. dev-java/castor # Patrice Clement (29 Oct 2015) # No release since 2007. Has dependencies on old ebuilds. # Removal in 30 days. See #564370 dev-db/octopus -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo-hosted code review
Sunday 01 Nov 2015 18:08:06, James Le Cuirot wrote : > On Mon, 2 Nov 2015 04:44:39 +1100 > Michael Palimaka wrote: > > > Phabricator also has all sorts of fancy (optional) features that could > > be useful for collaborative development (see http://phabricator.org/ > > for more info). > > > > What do you think? > > Looks nice! I hadn't heard of Phabricator before. It has a good mix of > open and closed projects using it, according to Wikipedia. I'm using > GitLab at work, which also does the job but Phabricator would probably > scale easier being PHP-based rather than Ruby-based; I say that as a > Ruby developer! I've had Gerrit recommended a few times but while I'm > sure it's capable, my brief encounters with it have found the interface > a little overwhelming. > > -- > James Le Cuirot (chewi) > Gentoo Linux Developer I would very much be able to emerge gerrit on Gentoo. There's no ebuild for it (yet). Someone filed a bug: https://bugs.gentoo.org/show_bug.cgi?id=409077 The Android Open Source project use Gerrit as its main code-review tool in their workflow. https://android-review.googlesource.com/#/q/status:open Diffs are shown side-by-side, which I find lacking on Github. Example: https://android-review.googlesource.com/#/c/175598/7/drivers/platform/goldfish/goldfish_pipe.c@179 Anyway, just my 2 cents on the topic. Have a look and you'll see in terms of features, I think it's on a par with Github. And it's open source. ;) -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Gentoo-hosted code review
Monday 02 Nov 2015 09:29:48, Duncan wrote : > Patrice Clement posted on Mon, 02 Nov 2015 09:33:49 +0100 as excerpted: > > > [gerrit] > > > > Anyway, just my 2 cents on the topic. Have a look and you'll see in > > terms of features, I think it's on a par with Github. And it's open > > source. ;) > > FWIW from previous gerrit suggestions... > > The problem there is ... java, along with the maintenance and security > issues it brings when run on a publicly accessible server where java is > otherwise unnecessary. (IIRC, at least one infra person said it's a hard > no on java running on gentoo infra, period, as it simply cannot be done > correctly and safely with the resources available. Tho I'm not 100% sure > IRC on that one.) > > #2 problem, as with several code-review products, is the security issue > of the huge stack of code (regardless of language) on a web server, with > direct single-user write access to the tree. If it were a different user > for each dev account so unconditional write access wasn't a monolithic > grant... > > Now if a one-way repo sync is done to the tree gerrit accesses from > gentoo-master, not reversed, sandboxing the tree gerrit has access too, > the problem is lessened to some degree, but of course that dramatically > lessens the usefulness as well, since the reviewed code must then be > checked back into the main tree manually. > > Which would seem to be one potential positive for phabricator, since at > least from the bit here in-thread, it appears to be review-only, no > direct commit access, thereby eliminating at least that security threat. > > -- > Duncan - List replies preferred. No HTML msgs. > "Every nonfree program has a lord, a master -- > and if you use the program, he is your master." Richard Stallman > > By reading your answer, I'm not sure if it is clear or obvious for most users how the workflow between the Gentoo infra <-> Github infra functions so maybe we should explain it one more time: 1) Gentoo developers receive notifications (emails) from Github that somebody's sent a PR and would like to merge it into the main repo 2) They go over to github.com/gentoo/gentoo/pulls and checkout the PR 3a) Sometimes (often), the PR has tons of errors and doesn't respect our coding standards and suddenly, we get a zillion notifications that mgorny and hasufell are peer-reviewing the PR ;) 3b) Sometimes the PR is spot on, the ebuild(s) submitted is (are) flawless, we merge it. 4) How do we merge it? We do *NOT* make use of the "Merge" button Github offers (and never will). Why? Changes would get lost in the wind if we did so, since the repository sitting on the Github infra is merely a mirror. Instead, we pull each PR into our own local copy of the Gentoo git repository hosted at https://gitweb.gentoo.org/repo/gentoo.git/ and then merge them. See: https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Workflow_walkthrough and https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Github_PRs_made_easy Think of Github as a nice and fancy UI to bridge the gap between developers and those allergic to a console and used to a browser. Now, with this explanation out of the way, I'm not sure what you mean by the "security threat" issue you've brought up your email. Gerrit is a code-review web platform that CAN allow commits to be merged, but this privilege has to be granted to specific users (like Github). It is really up to us and how infra want to manage merging. It doesn't make Gerrit less or more secure IMHO. This is a biased argument. -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
[gentoo-dev] Last rites: dev-java/{poi,dbunit} && dev-db/jxtray
# Patrice Clement (12 Nov 2015) # Upstream is somewhat alive but has made compiling POI difficult to compile # and package. Further, POI is affected by a bunch of CVEs. It has solely two # deps that we are masking as well since both projects are not very trendy # and/or alive. Masked for removal in 30 days. See bug #402757. dev-java/poi dev-java/dbunit dev-db/jxtray -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Last rites: net-p2p/phex
# Patrice Clement (12 Nov 2015) # Upstream dead + ebuild was never stabilised. # Masked for removal in 30 days. See bug #276095. net-p2p/phex -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-text/htmltidy
# Patrice Clement (21 Nov 2015) # Upstream dead + superseded by app-text/tidy-html5. # Masked for removal in 30 days. See bug #564884. app-text/htmltidy -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-p2p/deluge/
Monday 23 Nov 2015 18:18:49, Robin H. Johnson wrote : > On Mon, Nov 23, 2015 at 01:22:14PM +0000, Patrice Clement wrote: > > commit: 19c9530e8cf386649a0815cd532d24f6e7261867 > > Author: Paolo Pedroni users noreply github > > com> > > AuthorDate: Tue Nov 17 10:31:30 2015 + > > Commit: Patrice Clement gentoo org> > > CommitDate: Mon Nov 23 13:17:37 2015 + > > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=19c9530e > > > > net-p2p/deluge: Version bump. Fixes bug 561398. > > > > Gentoo-Bug: 561398 > > > > net-p2p/deluge/{deluge-1.3.11.ebuild => deluge-1.3.12.ebuild} | 1 + > > 1 file changed, 1 insertion(+) > This commit did NOT include any new Manifest entry, so stopped > replication to rsync (because we verify all Manifests now). > > If you git-pull/merge new ebuilds, please make sure you update the > Manifest! > > -- > Robin Hugh Johnson > Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee > E-Mail : robb...@gentoo.org > GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 > Oops. Thanks for the heads up and for fixing it. -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
[gentoo-dev] Last rites: dev-java/{many packages} app-text/epubcheck
# Patrice Clement (06 Dec 2015) # We maintain old versions which were never stabilised # and are too far behind for a trivial version bump. # Masked for removal in 30 days. See bug #161440. dev-java/webgraph dev-java/mg4j # Patrice Clement (05 Dec 2015) # Upstream dead: no update since 2007. # Masked for removal in 30 days. See bug #567580. dev-java/jpf dev-java/jpfcodegen # Patrice Clement (03 Dec 2015) # Broken and outdated. Let's see off these 3 packages. # Masked for removal in 30 days. See bug #567326. app-text/epubcheck dev-java/css-validator dev-java/jigsaw -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 02/13] python-utils-r1.eclass: Reorder implementations to semi-ascending order
Sunday 06 Dec 2015 20:03:21, Michał Górny wrote : > Reorder the Python implementations to ascending version order, with > CPython listed first and other implementations in descending preference. > > The previous ordering has been used for two reasons: > > 1. There were packages which supported Python 3.x or PyPy partially but > their documentation builds or test functions required CPython 2.x. > The specific ordering caused python_export_best (the predecessor of > python_setup) to use CPython 2.x for those tasks. This is now replaced > by explicit implementation restrictions in python_setup. > > 2. PyPy setup runs were usually slower than CPython, and CPython 3.x > runs were often slower due to 2to3 calls. Combined with parallel build > runs, this ordering caused slower builds to start earlier and sometimes > resulted in more efficient use of threads. However, nowadays we no > longer do parallel builds. > > Therefore, it seems reasonable to finally reorder the implementations > into a more intuitive order. > --- > eclass/python-utils-r1.eclass | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass > index 0bce6a9..3ea23a8 100644 > --- a/eclass/python-utils-r1.eclass > +++ b/eclass/python-utils-r1.eclass > @@ -41,10 +41,10 @@ inherit toolchain-funcs > # @DESCRIPTION: > # All supported Python implementations, most preferred last. > declare -g -r _PYTHON_ALL_IMPLS=( > - jython2_5 jython2_7 > - pypy pypy3 > - python3_3 python3_4 python3_5 > python2_7 > + python3_3 python3_4 python3_5 > + pypy pypy3 > + jython2_5 jython2_7 > ) > > # @FUNCTION: _python_impl_supported > -- > 2.6.3 > > Michal, While at it, please delete jython2_5 from this list since jython versions < 2.7 are in the process of being purged from Portage. See https://bugs.gentoo.org/show_bug.cgi?id=552452 Cheers, -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
Re: [gentoo-dev] News for Gentoo CI and pull request CI
Friday 11 Dec 2015 23:13:33, Michał Górny wrote : > Hi, everyone. > > I'd like to make a short announcement that in the last few days I've > been using my little free time to hack on my CI scripts, and they had > a few major improvements. Most notably: > > 1. pkgcheck now checks for outdated Manifests. In other words, > gentoo-ci will most likely complain about missing or extraneous > Manifest entries before Infra does, and pull request checks should > complain loudly about them before the PRs are merged. > > 2. The scripts use XML output of pkgcheck and group issues by packages, > rather than grepping text output for failure indications > and considering successive lines a single failure. Which means better > output, better permalinks, better navigation and a completely new ugly > UI. > > 3. Most of the persisting issues (like deprecations) are skipped now, > and all the output fits on one page. And that page is usually easier on > the browser than each of the splits were. > > 4. gentoo-ci compares previous check results correctly, and splits > the output into three groups: new issues, previous issues and fixes > issues. > > 5. gentoo-ci bisects on new issues, pinpoints the exact commit > introducing the failure and CCs both the author and the committer. > In other words, does the hard work for me and does it more efficiently. > It also has nice bisect caching support which makes bisecting a number > of issues caused by the same commit very fast. > > 6. pull-request checks now distinguish between issues introduced by PR > and carried over from ::gentoo. Not that you should ignore the latter > entirely since they may hide additional issues from PR. > > Most of this fun stuff came from a simple obvious thing that only > recently occurred to me: I don't have to run a full pkgcheck for > bisecting! I just need to check the packages that are failing > in the most recent commit! > > Of course, the whole thing is open source: > > 1. https://bitbucket.org/mgorny/repo-mirror-ci > > 2. https://bitbucket.org/mgorny/pkgcheck-result-parser > > Enjoy! > > -- > Best regards, > Michał Górny > <http://dev.gentoo.org/~mgorny/> Awesome Michal, thanks a lot! -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Last rites: www-client/uzbl
# Patrice Clement (05 Jan 2016) # According to its maintainer. this project is slowly dying # and there's no activity occuring on mailing lists / git repo. # Masked for removal. See bug 570836. www-client/uzbl -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-java/struts
# Patrice Clement (06 Jan 2016) # Struts 2 and friends suffer from a lack of interest. These ebuilds are # outdated, riddled with CVEs (about 5 currently opened in Bugzilla) and some # of them do not compile at all. Time to see them off. # Masked for removal in 30 days. See bug #540888. dev-java/struts-plugins dev-java/struts-xwork dev-java/struts-core dev-java/struts -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] New project: Shell tools
In preparation for the implementation of GLEP 67, members of the Shell tools herd are announcing the Shell tools project [1], which will replace the old herd. [1] https://wiki.gentoo.org/wiki/Project:Shell_Tools -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Herd likely up for grabs: net-irc
Sunday 17 Jan 2016 21:16:45, Michał Górny wrote : > Hello, everyone. > > The current maintainers of net-irc herd so far haven't replied to > our queries. If we don't get any reply in a week, we will be disbanding > it and looking for new maintainers for its packages. > > Is anyone interested in keeping the herd as a whole and maintaining all > of its packages? If nobody replies till 2016-01-24, the herd will be > automatically disbanded and I will be sending a complete list of > packages needing maintainers. > > Packages currently in herd along with their other maintainers: > > [...] > net-irc/irssi: swegener@ > net-irc/irssi-otr: > net-irc/irssistats : > > -- > Best regards, > Michał Górny > <http://dev.gentoo.org/~mgorny/> Avid user of irssi here. I'd like to take these 3 please. -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings
Tuesday 19 Jan 2016 00:44:49, NP-Hardass wrote : > With all of the unclaimed herds and unclaimed packages within them, I > started to wonder what will happen after the GLEP 67 transition > finally comes to fruition. This left me with some concerns and I was > wondering what the community thinks about them, and some possible > solutions. > > There is a large number of packages from unclaimed herds that, at this > time, look like they will not be claimed by developers. This will > likely result in a huge increase in maintainer-needed packages (and > subsequent package rot). This isn't to say that some of these > packages weren't previously in a "maintainer-needed" like state, but > now, they will explicitly be there. > > A possible approach to reducing this is to adopt some new policies. > > The first of which is an "adopt-a-package" type program. In > functionality, this is no different than proxy-maintenance, however, > this codifies it into an explicit policy whereby users are encouraged > to step and take over a package. This obviously requires a greater > developer presence in the proxy-maint project (or something similar), > but, personally, I think that a stronger dev presence in proxy-maint > would be better for Gentoo as a whole. > > The second policy change would be that maintainer-needed packages can > have updates by anyone while maintaining the standard "you fix it if > you break it" policy. This would extend to users as well. With the > increased ease that users can contribute via git/github, they should > be encouraged to contribute and have their efforts facilitated to ease > contributions to whatever packages they desire (within the > maintainer-needed category). > > Similar to the concept of a "bugday," coupled with above, an > "ebuildday" where users and devs get together so users can learn to > write ebuilds and for devs to work together to maintain packages that > usually fall outside their normal workload could prove beneficial to > the overall health of Gentoo packaging. > > Once again, these are just some random musings inspired by recent > events on the dev ML, and thought it might be worth discussing. > I've cc'd proxy-maint as a lot of this discussion is likely to involve > them, and would like them to put in their official opinion as well. > > > -- > NP-Hardass More food for thought on the topic of "what do we do with maintainer-wanted packages". NP-Hardass I quite like your idea but what about clearing down the massive queue of reports assigned to maintainer-wanted first? Right now, the number of bug reports assigned to maintainer-wanted amounts to over 4k: http://tiny.cc/maintainer_wanted There's literally a slew of reports we can mark as WONTFIX / OBSOLETE because, well, some of these bugs are over 10 years old (!) and a lot of projects have stalled / are dead by now / or the industry has moved on. It has to be done at some point anyway so better now than later. And the upside is that it doesn't require ebuild skills or knowing Gentoo by heart: only clicking links and checking whether projects are still alive. What do you think? -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2 08/19] ebuild-maintenance: rewrite the text on adding binary files to the tree #558642
Sunday 24 Jan 2016 03:46:02, Gokturk Yuksek wrote : > Remove the paragraph about adding binary files to CVS. > Replace the instances of CVS with git. > > X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558642 > Signed-off-by: Gokturk Yuksek > --- > ebuild-maintenance/text.xml | 19 +++ > 1 file changed, 3 insertions(+), 16 deletions(-) > > diff --git a/ebuild-maintenance/text.xml b/ebuild-maintenance/text.xml > index ac68dcd..10709ea 100644 > --- a/ebuild-maintenance/text.xml > +++ b/ebuild-maintenance/text.xml > @@ -42,22 +42,9 @@ above 20KB) which should be distributed as tarballs via the > Gentoo > mirror system > so that people do not waste excessive amounts of bandwidth and hard drive > space. Also, you should not add binary (non-ASCII) files to the > -Portage CVS tree. If you need to do this in another CVS tree, for > -example, if you need to add a small PNG graphic for whatever reason, > -be sure to add it to CVS by using the -kb option, like so: > - > - > - > -# cvs add -kb myphoto.png > - > - > - > -The -kb option tells CVS that myphoto.png is a binary > -file and should be treated specially. For example, merging the > -differences between two different versions of this file should not be > -allowed to happen, for obvious reasons. Also, speaking of merging > +git tree. Also, speaking of merging > changes, any patches you add to Portage should generally not be > -compressed. This will allow CVS to merge changes and correctly inform > +compressed. This will allow git to merge changes and correctly inform > developers of conflicts. > > > @@ -149,7 +136,7 @@ simply, 1.0-gentoo.diff. Also note that the > gentoo extension informs people that this patch was created > by us, the Gentoo Linux developers, rather than having been grabbed from a > mailing list or somewhere else. Again, you should not compress these > -patches because CVS does not play well with binary files. > +patches because git does not play well with binary files. > > > > -- > 2.4.10 > > "Again you should not compress these patches because git does not play well binary files". I'm not sure this statement still holds true with git. Does it? -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
Re: [gentoo-dev] Gentoo Bugzilla 5 upgrade completed
Monday 01 Feb 2016 05:53:52, Robin H. Johnson wrote : > Hi everybody, > > Idl0r has done all the work to upgrade us to Bugzilla's latest major > version, v5.0, from upstream. > > Please report bugs in the usual place (product=Gentoo Infrastructure, > component=Bugzilla). > > Sorry for the extended outage: the last portion, running the > collectstats.pl script took much longer than originally estimated, as it > seemed to be CPU-bound on the host (not the DB in any way). > > -- > Robin Hugh Johnson > Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee > E-Mail : robb...@gentoo.org > GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 > This is great news! Thanks a lot for your work. Goodbye {JSON,XML}RPC, hello REST! [1] [1]: https://wiki.mozilla.org/Bugzilla:REST_API -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
[gentoo-dev] [Fwd: [gentoo-automated-testing] BROKEN: repository became broken!]
Hi dlan 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? Thank you! - Forwarded message from mgo...@bonedaddy.net - > From: mgo...@bonedaddy.net > Subject: [gentoo-automated-testing] BROKEN: repository became broken! > To: gentoo-automated-test...@lists.gentoo.org > CC: d...@gentoo.org > Date: Mon, 01 Feb 2016 03:31:56 + > > Looks like someone just broke Gentoo! > > New issues: > https://qa-reports.gentoo.org/output/gentoo-ci/780f65b/output.html#dev-libs/efl > > > Introduced by commits: > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=97a6aec > > > Changes since last check: > https://gitweb.gentoo.org/repo/gentoo.git/log/?qt=range&q=2496d1d..37c79f8 > > -- > Gentoo repository CI > - End forwarded message - -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
Re: [gentoo-dev] games.eclass policy
Sunday 07 Feb 2016 11:38:27, M.B. wrote : > > Hello folks. > > While hacking away on a new ebuild I came across the issue that > games.eclass apparently got banned from future use. The only references > I was able to dig up (apart from helpful people on IRC), were > https://bugs.gentoo.org/show_bug.cgi?id=566498 (games.eclass: use of > games group needs to be removed wrt 20151011 Council meeting) > and > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Games_team_policies_issue > (A mere deprecation notice). > > In contrast, a simple "grep deprec /usr/portage/eclass/" gives numerous > deprecation warnings; just games.eclass is not among them. > > Please provide some guidance how (community-)developers are supposed to > handle games (in particular wrt games.eclass) in the future. This also > includes usage of /usr/games/{bin/lib/share} etc. > > Regards, > tomboy64 > > Good point. I too came across this problem when dealing with another bug (games-emulation/ppsspp). A user filed a bug, complaining the ebuild wasn't installing the compiled binary in /usr/games and suggested it should inherit the games eclass: https://bugs.gentoo.org/show_bug.cgi?id=572606#c12 I wasn't aware of the ban too so if someone has a better solution, I'm all ears. Regards, -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
[gentoo-dev] Last rites: net-libs/iojs
# Patrice Clement (08 Feb 2016) # iojs and nodejs merged and formed the new major version nodejs 4.0. iojs will # not be maintained after 3.3.x and all users are suggested to move to nodejs 4 # (or newer) as quick as possible to avoid any security-related issues. # Masked for removal in 30 days. See bug 573870. net-libs/iojs -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Automatic Bug Assignment
Saturday 30 Jan 2016 11:45:48, Alex Brandt wrote : > Hey Guys, > > I've oft wondered why we don't automatically assign bugs to the > ebuild maintainer (if a CPV is in the subject). Would there be an > issue with adding a bug modification hook to bugzilla or a daily > job to re-assign bugs to ebuild owners (if a CPV is in the > subject)? > > Just curious not trying to incite anything. > > Regards, > > -- > Alex Brandt > Software Developer for Rackspace and Developer for Gentoo > http://blog.alunduil.com Alex I like your idea (I tought about it a while ago but never bothered raising the issue on the gentoo-dev ML). So I looked around on the Internet to see if there's another open source project like Gentoo who ran into a similar issue with Bugzilla. And it turns out there is (!). Context: the FreeBSD project recently ditched GNATS in favour of Bugzilla [1]. FreeBSD devs now make heavy use of the bug tracker and like us, they try to optimise Bugzilla and fine-tune it as best as they can. And like us, they ran into this similar issue: how to automatically assign bugs. So they put together a Bugzilla extension to fix this problem. Code is available here [2]. Since it's already been implemented, no need to reinvent the wheel, we can find inspiration through their code. However, I'm not familiar at all with this code. If you have questions or want to find out more, don't ask me, ask them! FreeBSD devs hang out in #freebsd-bugs on freenode (at least the Bugzilla team). They've been really helpful so far and are a delight to talk to. [1]: https://lists.freebsd.org/pipermail/freebsd-announce/2014-June/001559.html [2]: https://github.com/freebsd/bugzilla/tree/freebsd-local/extensions/FBSDAutoAssign Cheers, -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Last rites: java-virtuals/jaxp && dev-java/jax{p,b,-ws,-ws-api,r} && dev-java/jsr93
# Patrice Clement (09 Feb 2016) # Old, ancient, deprecated, obsolete.. so many adjectives could describe these # ebuilds. Let's just say it's about time to kiss them goodbye. # Masked for removal in 30 days. See bug 566232. java-virtuals/jaxp-virtual dev-java/jaxp dev-java/jaxb dev-java/jax-ws dev-java/jax-ws-api dev-java/jaxr dev-java/jsr93 -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-vcs/stat{svn,cvs}
# Patrice Clement (14 Mar 2016) # No activity nor release since 2010. Does not compile with Java 8. # Masked for removal. See bug 577368. dev-vcs/statsvn dev-vcs/statcvs -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-java/freehep-*
# Patrice Clement (17 Apr 2016) # Unmaintained ebuilds (EAPI 0!) which don't compile with Java 8. # Removal in 30 days. See bug 580094. dev-java/freehep-export dev-java/freehep-graphics2d dev-java/freehep-graphicsio dev-java/freehep-graphicsio-emf dev-java/freehep-graphicsio-java dev-java/freehep-graphicsio-pdf dev-java/freehep-graphicsio-ps dev-java/freehep-graphicsio-svg dev-java/freehep-graphicsio-swf dev-java/freehep-graphicsio-tests dev-java/freehep-io dev-java/freehep-mcfio dev-java/freehep-misc-deps dev-java/freehep-parameterdatabase dev-java/freehep-record dev-java/freehep-rootio dev-java/freehep-rtti dev-java/freehep-sio dev-java/freehep-stdhep dev-java/freehep-swing dev-java/freehep-util dev-java/freehep-xdr dev-java/freehep-xml -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] On banning merge commits
Hi gents After yet another discussion about git in the #gentoo-dev channel tonight, the topic of merge commits came up for the umpteenth time. We all seem to agree merge commits are really bad design, add clutter to the log graph after a while and should be banned altogether from reaching the central repository. As of now, no policy is in place yet to keep developers from pushing merge commits. What is the correct course of action? I would very much like it to be worded in a document (GLEP and/or Wiki page) so that confusion is avoided and we all are on the same page on this topic. Cheers, -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place
Thursday 19 May 2016 23:08:05, Mike Frysinger wrote : > On 18 May 2016 22:25, aide...@gentoo.org wrote: > > awk doesn't have the -i option like sed and if editing file in place is > > desired, additional steps are required. eawk uses tmp file to make it > > look to the caller editing happens in place. > > what's your real use case ? i've never once thought "man, i wish i could > run an awk script and modify a file in place". and i write awk most days. > -mike Same question. Why would you ever want to run awk and have it in-place edit a file? Have you ever heard about Perl? In place editing a file with it is as easy as ABC: $ perl -i'' -ne 's/foo/bar/g;' file.txt And you're done. If you don't fancy Perl, you could use Ruby with the exact same syntax and it works just as well. Then add either of these to DEPEND and you're set. Please walk us through why you actually want this function to be added cause I read this thread and your diff like 10 times and couldn't come up with a sensible reason which would justify this change. -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] git-r3.eclass: Support EGIT_SUBMODULES to filter used submodules, #497164
Monday 23 May 2016 21:54:19, Michał Górny wrote : > --- > eclass/git-r3.eclass | 53 > +++- > 1 file changed, 52 insertions(+), 1 deletion(-) > > diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass > index 957ff08..61218a8 100644 > --- a/eclass/git-r3.eclass > +++ b/eclass/git-r3.eclass > @@ -165,6 +165,36 @@ fi > # > # EGIT_CHECKOUT_DIR=${WORKDIR}/${P} > > +# @ECLASS-VARIABLE: EGIT_SUBMODULES > +# @DEFAULT_UNSET > +# @DESCRIPTION: > +# An array of inclusive and exclusive wildcards on submodule names, > +# stating which submodules are fetched and checked out. Exclusions > +# start with '-', and exclude previously matched submodules. > +# > +# If unset, all submodules are enabled. Empty list disables all > +# submodules. In order to use an exclude-only list, start the array > +# with '*'. > +# > +# Remember that wildcards need to be quoted in order to prevent filename > +# expansion. > +# > +# Examples: > +# @CODE > +# # Disable all submodules > +# EGIT_SUBMODULES=() > +# > +# # Include only foo and bar > +# EGIT_SUBMODULES=( foo bar ) > +# > +# # Use all submodules except for test-* but include test-lib > +# EGIT_SUBMODULES=( '*' '-test-*' test-lib ) > +# @CODE > +if [[ ${EGIT_SUBMODULES[@]+1} && $(declare -p EGIT_SUBMODULES) != "declare > -a"* ]] > +then > + die 'EGIT_SUBMODULES must be an array.' > +fi > + > # @FUNCTION: _git-r3_env_setup > # @INTERNAL > # @DESCRIPTION: > @@ -243,7 +273,8 @@ _git-r3_env_setup() { > if [[ ${EGIT_HAS_SUBMODULES} ]]; then > eerror "EGIT_HAS_SUBMODULES has been removed. The eclass no > longer needs" > eerror "to switch the clone type in order to support submodules > and therefore" > - eerror "submodules are detected and fetched automatically." > + eerror "submodules are detected and fetched automatically. If > you need to" > + eerror "disable or filter submodules, see EGIT_SUBMODULES." > die "EGIT_HAS_SUBMODULES is no longer necessary." > fi > > @@ -357,6 +388,26 @@ _git-r3_set_submodules() { > l=${l#submodule.} > local subname=${l%%.url=*} > > + # filter out on EGIT_SUBMODULES > + if declare -p EGIT_SUBMODULES &>/dev/null; then > + local p res= l_res Watch out for the extra space. > + for p in "${EGIT_SUBMODULES[@]}"; do > + if [[ ${p} == -* ]]; then > + p=${p#-} > + l_res= > + else > + l_res=1 > + fi > + > + [[ ${subname} == ${p} ]] && res=${l_res} > + done > + > + if [[ ! ${res} ]]; then > + einfo "Skipping submodule \e[1m${subname}\e[22m" > + continue > + fi > + fi > + > # skip modules that have 'update = none', bug #487262. > local upd=$(echo "${data}" | git config -f /dev/fd/0 \ > submodule."${subname}".update) > -- > 2.8.3 > > -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
[gentoo-dev] [gentoo-dev-announce] Last rites: dev-util/{osdt,weblint}
# Patrice Clement (2 Jun 2016) # Ancient software (1996!). Unmaintained. # Masked for removal in 30 days. dev-util/weblint # Patrice Clement (2 Jun 2016) # Dead upstream. No release since 2009. # Masked for removal in 30 days. dev-util/osdt -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
[gentoo-dev] [gentoo-dev-announce] Last rites: dev-util/{...}
# Patrice Clement (5 Jun 2016) # Unmaintained ebuilds. Upstream is either dead or AWOL. Also, most of these # ebuilds are still sitting in ~arch after years in the tree. # Masked for removal in 30 days. dev-util/ccmalloc dev-util/dwarves dev-util/tinlink dev-util/cdecl dev-util/redet dev-util/eggy dev-util/mock dev-util/par dev-util/injectso dev-util/dissembler dev-util/ghh dev-util/lsuio dev-util/rec dev-util/usb-robot dev-util/jif dev-util/httpup dev-util/crow-designer dev-util/qdevelop dev-util/intel2gas dev-util/webcpp dev-util/as11 dev-util/duma dev-util/filepp dev-util/pretrace dev-util/ald dev-util/kdoc dev-util/skelgen dev-util/ftncheck -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] app-text/htmltidy: Maintainer Request
Sunday 05 Jun 2016 19:39:26, Yury German wrote : > app-text/htmltidy currently has no maintainers. It has a vulnerability > [Security Bug] filed against it. And a number of other [package depend > on it]. Is nyone willing to pick it up? > > [Secuity Bug] > https://bugs.gentoo.org/show_bug.cgi?id=561452 > > [package depend on it] > https://qa-reports.gentoo.org/output/genrdeps/dindex/app-text/htmltidy > https://qa-reports.gentoo.org/output/genrdeps/rindex/app-text/htmltidy > > __ > Yury German > GLSA Coordinator | Gentoo Security Team > Administrator| Planet Gentoo > Email: bluekni...@gentoo.org > > GPG Fingerprint: 8858 89D6 C0C4 75C4 D0DD FA00 EEAF ED89 024C 043 > Don't bother. Have a look at [1], [2] & [3] to find out why. tl;dr htmltidy has got to be culled at some point since it's now considered obsolete after tidy-html5 entered the tree a little while ago. It's roughly the same codebase yet it's HTML 5 compliant. Yay! I've been maintaining the latter since its inclusion in the Portage tree but would definitely need help to remove the former. I didn't swap htmltidy for tidy-html5 cause they're two different projects. As you can see from the links above, htmltidy has a gazillion deps. [1]: http://tidy.sourceforge.net/ [2]: http://www.html-tidy.org/ [3]: https://github.com/htacg/tidy-html5 -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] [gentoo-dev-announce] Last rites: dev-libs/vrb
# Patrice Clement (10 Sep 2016) # Upstream dead. This package tries very hard to outsmart autotools and # reinvent the wheel by coming up with its own configure script. A complete # disaster resulting in a gigantic wave of QA errors. # Masked for removal in 30 days. dev-libs/vrb -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-java/jmf-bin
# Patrice Clement (09 Oct 2016) # Although still available for download, the JMF API is a dead project which # hasn't been updated in years and hence very old. # Masked for removal in 30 days. dev-java/jmf-bin -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-python/pylons*
# Patrice Clement (10 Oct 2016) # Note from upstream (https://github.com/Pylons/pylons): # Pylons has merged with repoze.bfg, and is now in maintenance-only mode. It's # highly recommended that new projects start with the new merged web framework, # pyramid. Masked for removal in 30 days. dev-python/pylons-sphinx-themes dev-python/pylons -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Local workarounds with no reported bugs
Monday 17 Oct 2016 09:23:09, Michał Górny wrote : > Hello, everyone. > > I'd like to point out a major problem in Gentoo: there's a fair number > of developers who add various local workarounds to problems they meet > and don't bother to report a bug. Worst than that, this applies not > only for upstream problems but also to Gentoo eclass/ebuild-related > issues. > > --8<--snip--8<--snip--8<--snip--8<--snip--8<-- > > Therefore, I'd like to request establishing an official policy against > workarounds with no associated bug reports. > > Your thoughts? > > -- > Best regards, > Michał Górny > <http://dev.gentoo.org/~mgorny/> Michal You're being emotional in my opinion and as a result, are painting *all* Gentoo developers with a broad brush. Relax. We don't need yet another policy to "fix" two problems you've encountered, this sounds silly. To be honest, I don't understand your 2nd example: a change was made in an eclass and as all eclass changes, these need to be discussed either here on the mailing list or via IRC. You seem to be maintainer of git-r3; who made the commit? did you sign off on it? if not, why was it merged? etc. Give us a bit more context please. Your message looks more like a rant rather than a rational proposal. Cheers, -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Dealing with GitHub Pull Requests the easy way
Hello fellow Gentoo developers and subscribers of the gentoo-dev mailing list, I've been wanting to write this email for a while but for some reason never got round to doing it due to lack of motivation and time. I will be discussing many topics in this email revolving around git essentially. I first want to go over some basic concepts about git and GitHub and why we should be doing things differently if we want to avoid cluttering up our repository with useless stuff. * Background As you know, a little while ago we've migrated the main tree to git, the revision control tool which needs no introduction. A few months after the migration, our repository was mirrored over to GitHub to give the project a bit more exposure to what some developers refers to as "the GitHub generation". The response from the community was extordinary and as a result, a massive number of Pull Requests came our way. We soon then started to lend ourselves to the duty of PR triaging and merging, and started to make what's called in the git world "merge commits". Understanding merge commits requires understanding how GitHub considers a contribution. When a contributor sends a PR via GitHub, he will essentially be making a different branch, start working on it and eventually file it. For those of you familiar with git or who've already filed PRs on GitHub, this is old news. However, there's a number of different way to deal with PRs on the receiving end (us) in order to keep a sane log history (graph actually). When we first started working with git, and GitHub, the tendency was to rely on merge commits to merge contributions back into the main repo. In my opinion, this was, and still is, a bad idea. What's so special about merge commits? * A short walk through merge commits As you may know, merging one branch into another often results in creating a new commit. This commit is called a "merge commit" in git jargon. Let's pick for instance cf4cce36684de5e449ec60bde3421fa0e27bac74. I'm not trying to put the blame on a particular developer, we've all used merge commits at one point or another and I was one of the first! In the log graph, this commit is displayed as such: $ git log --graph --oneline master [snip] * | | cf4cce3 Merge remote-tracking branch 'github/pr/1845' |\ \ \ | * | | abf61de net-im/ejabberd: require https://github.com/gentoo/gentoo/pull/1234.patch Once fetched, using your favourite web crawler, the patch can be directly applied via the git am command onto HEAD of the repository you're dealing with. There's this common idiom for fetching AND applying at patch all at once: $ curl https://github.com/gentoo/gentoo/pull/1234.patch | git am * This is where I'm meant to sell you my solution Ultimately, I've decided to write a tool to leverage this way of fetching PRs and merging them. The tool is called Gentoo-App-Pram and is available in the tree: # emerge Gentoo-App-Pram It is written in Perl, works fairly well and has been used by a fair (growing?) number of developers so far. The tool is CLI-based so you will need to feel at home with the command line. Once emerged, cd into your Gentoo git repo and type `pram' followed by the PR number you wish to merge: $ cd /home/patrice/gentoo $ pram 1234 pram will then fetch the PR as a patch and display it to you in your favourite $EDITOR. At this point, you can make any change to the PR i.e. editing commit message(s), changing code in-line, etc. pram also leverages the "Closes:" header. This header is recognised by GitHub, and Larry the Cow, and will automatically close a PR when parsing it in the body of a commit message. So for instance, the following header will automatically close PR 1234: "Closes: https://github.com/gentoo/gentoo/pull/1234";. You don't need to manually add it as pram will do this for you. After saving and getting out of $EDITOR, pram will ask you whether the PR needs merging by asking a yes/no question. "y" will launch git am and merge the patch whereas "n" will abort the operation and clean it up. That's pretty much it. Make sure to read the man page since there are other options available (pram --man). pram wouldn't have been possible without Kent Fredric's help. He's assisted me in releasing the package on CPAN and contributed a few patches. Kudos to him! To wrap up: - Please stop making merge commits. This strategy is not useful in the case of Gentoo and does more harm than good. - Cherry-pick or git-am external contributions such as PRs. - Better yet, use Gentoo-App-Pram. :-) If you want to contribute to Gentoo-App-Pram, send me a PR on GitHub at https://github.com/monsieurp/Gentoo-App-Pram or file a bug report at https://bugs.gentoo.org and assign it to me. Comments and suggestions welcome. Cheers, -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Tinderboxing efforts in Gentoo
Friday 02 Dec 2016 14:10:27, Michał Górny wrote : > Hi, everyone. > > I've heard multiple times about various tinderbox projects being > started by individuals in Gentoo. In fact, so many different projects > that I've forgotten who was working on most of them. > > I know that Toralf is doing tinderboxing for most of the stuff. > What other projects do we have there? What is their status? > > Is there anything we could try to integrate with pull requests to get > a better testing? > > -- > Best regards, > Michał Górny > <http://dev.gentoo.org/~mgorny/> Continuous integration is all the rage these days and tinderboxing is the obvious way to go concerning Gentoo. AFAIK, Toralf is the only contributor doing tinderboxing out of his own will. In reality, we should have a team of devs looking after our own tinderboxes instead of relying on the community. I'm wondering if we could start a donation campain for this project and ask people if they've got spare machines laying around. I know a lot of folks are reading this mailing list so maybe asking on gentoo-dev first for a start would be appropriate. Otherwise, can the Foundation sponsor the purchase of a couple of servers? -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-java/jusb
# Patrice Clement (11 Mar 2017) # Upstream dead: no update since 2003. Ebuild is outdated and buggy. # Removal in 30 days. Bug #279088 dev-java/jusb -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] [gentoo-dev-announce] Last rites: dev-java/swidgets
# Patrice Clement (18 Mar 2017) # Does not compile anymore. Upstream dead. # Removal in 30 days. dev-java/swidgets -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
[gentoo-dev] [gentoo-dev-announce] Last rites: dev-java/swing-worker
# Patrice Clement (28 Mar 2017) # Part of the JRE since Java 6. Removal in 30 days. dev-java/swing-worker -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-java/jaxme
# Patrice Clement (07 Apr 2017) # Part of the JDK since Java 6. Removal in 30 days. dev-java/jaxme -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
[gentoo-dev] [gentoo-dev-announce] Last rites: dev-java/jdbc-jaybird
# Patrice Clement (20 Jun 2017) # Fails to build with Java 8. Project is active on Github yet ebuild has never # been marked stable. # Masked for removal in 30 days. dev-java/jdbc-jaybird -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
[gentoo-dev] Re: [RFC] NeoVim and vim-syntax
Hi Vadim and thank for your email. Sorry for taking so long to respond, been busy with work, life, etc. Thursday 01 Jun 2017 02:32:24, Vadim A. Misbakh-Soloviov wrote : > Currently, we have a situation, that there are two Vim's: "old" one (vim8) > and > NeoVim (for those who do not know: a fork of Vim with much and much more > clean > code, many neat features and so on). Vim8 is here to stay and has served us well until now. Calling him "old" is unfair. :) To be honest, I haven't given NeoVim a try yet (should I?). > > Unfortunately, both of them have different runtimedirs: XDG ones for NeoVim > and the ones you know for Vim8, while NeoVim is fully compatible with Vim's > plugins, and epecially with vimscripts (like syntax definitions and ftdetect > scripts). ACK. I have one question though: will this retrocompatibility last forever? > > On the other side, we have a bunch of packages in the portage tree, that have > "vim syntax" support (use-flags, or direct vim-syntax packages), or even vim- > plugins. > All of them goes to `/usr/share/vim/vimfiles`, while correct path for NeoVim > would be `/usr/share/nvim/site` (does not exist at the moment, but nvim > checks > for it). That's good to know. > > So, that situation leads to impossibility to get all of that syntax > definitions > and plugins when user uses NeoVim. > > As I said above, NeoVim supports Vim's plugins/scripts very well (although I > didn't find any evidence of the opposite), so it is possible to fix that > situation by many of "kludge" ways, including: > > - implementing "nvim-syntax" (and `app-nvim/*`?) and duplicate all the > installed files This sounds like a lot of duplicate work for very little gain. > > - patching NeoVim source to include Vim's runtimedirs (incl. "after" dir), > // NeoVim upstream highly disagree with such way, if any Very appealing. Why is NeoVim upstream against this solution by the way? Truth to be told, we can have it our way and patch NeoVim so that it behaves however we like. > > - patching VIMRUNTIME environment variable, Who would need patching in this case: NeoVim or Vim8? > > - making a wrapper, A good approach as well. Will need a bit of maintainenance. > > - rewrite all the existing ebuilds to take nvim into account and force all > newcomers to also take it, Too much work. > > - symlinking a directory, > // mostly bad way, since opposite plugin compatibility is not garanteed and > users can install nvim-only plugins in the future idea-- > > - making postinst hook to regenerate content of NeoVim's site-directory > (maybe, by symlinking installed vim modules there) Ew. > > or even: > > - making eselect module for user to rule that. > > Although, talking on eselect module, I've two visions of the situation: > a) it can be something like bashcomp module, where users can select which of > installed vim modules they want to "enable" in NeoVim > or (better, imo) way: > b) it can be something like php module, where portage installs all the stuff > in the location neither available to Vim nor NeoVim, and users selects which > modules they enable for either implementation. > > Module can be called something like "eselect-vim" or "eselect-vim-modules" > (?), if any. To be honest, the eselect idea looks very convoluted. Why? Please correct me if I'm wrong but by design, most, of not all, modules can be enabled or disabled via the .vimrc file. It only takes a single line in your personal .vimrc file if you wish a module not to load at runtime. I fail to see the added value of an eselect module for solving a task Vim already handles very well. > > > For now, I have preview of neither of eselect module variants, nor even > patches for another "ways". I'd very like to discuss the situation and find a > better of possible solution first. > Maybe, when (if?) we found such a solution, I'd contribute a PR with it on GH. > > -- > wbr, > mva So here you have it. I'm fine with knocking together a wrapper or patching NeoVim sources. Do you think it's a big deal to put NeoVim modules in the app-vim category? It makes more sense to me to keep everything under the same umbrella. Cheers -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
Re: [gentoo-dev] vim-syntax USE flag
Hi Mike Saturday 22 Jul 2017 16:27:39, Mike Gilbert wrote : > Packages currently handle installation of vim syntax support files > inconsistently. Some builds install the files if the "vim-syntax" USE > flag is enabled, while others install them unconditionally. > > Do these files fall into the "small text files" category for > unconditional installation? If so, we should probably phase out the > vim-syntax USE flag. > > If we want to keep the USE flag, I would suggest documenting a global > policy regarding its use. Should that live in the devmanual? Or maybe > the Vim project page? > Do you have a list handy of packages installing the vim syntax files unconditionally? I can look into this issue. -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
Re: [gentoo-dev] New package neomutt
|| ( www-client/lynx www-client/w3m www-client/elinks ) > + )" > +RDEPEND="${CDEPEND} > + selinux? ( sec-policy/selinux-mutt ) > +" > + > +S="${WORKDIR}/${PN}-${P}" > + > +src_prepare() { > + eapply_user > + eautoreconf > +} > + > +src_configure() { > + local myconf=( > + "$(use_enable crypt pgp)" > + "$(use_enable debug)" > + "$(use_enable doc)" > + "$(use_enable gpg gpgme)" > + "$(use_enable nls)" > + "$(use_enable smime)" > + "$(use_enable notmuch)" > + "$(use_with idn)" > + "$(use_with kerberos gss)" > + "--with-$(use slang && echo slang || echo > curses)=${EPREFIX}/usr" > + "--sysconfdir=${EPREFIX}/etc/${PN}" > + "--with-docdir=${EPREFIX}/usr/share/doc/${PN}-${PVR}" > + ) > + > + if [[ ${CHOST} == *-solaris* ]] ; then > + # arrows in index view do not show when using wchar_t > + myconf+=( "--without-wc-funcs" ) > + fi > + > + # mutt prioritizes gdbm over bdb, so we will too. > + # hcache feature requires at least one database is in USE. > + local hcaches=( > + "tokyocabinet" > + "qdbm" > + "gdbm" > + "berkdb:bdb" > + ) > + local ucache hcache lcache > + for hcache in "${hcaches[@]}" ; do > + if use ${hcache%%:*} ; then > + ucache=${hcache} > + break > + fi > + done > + for hcache in "${hcaches[@]}" ; do > + [[ ${hcache} == ${ucache} ]] \ > + && myconf+=( "--with-${hcache#*:}" ) \ > + || myconf+=( "--without-${hcache#*:}" ) > + done Can you simplify this code a little? > + > + # there's no need for gnutls, ssl or sasl without socket support > + if use gnutls; then > + myconf+=( "--with-gnutls" ) > + elif use ssl; then > + myconf+=( "--with-ssl" ) > + fi > + # not sure if this should be mutually exclusive with the other two > + myconf+=( "$(use_with sasl)" ) > + > + if use mbox; then > + myconf+=( "--with-mailpath=${EPREFIX}/var/spool/mail" ) > + else > + myconf+=( "--with-homespool=Maildir" ) > + fi > + > + econf "${myconf[@]}" || die "configure failed" econf dies on its own, please nix || die. > +} > + > +src_install() { > + emake DESTDIR="${D}" install || die "install failed" > + if use mbox; then > + insinto /etc/neomutt > + newins "${FILESDIR}"/Muttrc.mbox Muttrc > + else > + insinto /etc/neomutt > + doins "${FILESDIR}"/Muttrc > + fi > + > + # A newer file is provided by app-misc/mime-types. So we link it. > + rm "${ED}"/etc/${PN}/mime.types Please append || die here. > + dosym /etc/mime.types /etc/${PN}/mime.types > + > + # A man-page is always handy, so fake one > + if use !doc; then > + emake -C doc DESTDIR="${D}" muttrc.man || die emake dies on its own. > + # make the fake slightly better, bug #413405 > + sed -e > 's#@docdir@/manual.txt#http://www.mutt.org/doc/devel/manual.html#' \ > + -e 's#in @docdir@,#at http://www.mutt.org/,#' \ > + -e "s#@sysconfdir@#${EPREFIX}/etc/${PN}#" \ > + -e "s#@bindir@#${EPREFIX}/usr/bin#" \ > + doc/mutt.man > mutt.1 Ditto, append || die here as well. > + cp doc/muttrc.man muttrc.5 Ditto. > + doman mutt.1 muttrc.5 > + else > + # nuke manpages that should be provided by an MTA, bug #177605 > + rm "${ED}"/usr/share/man/man5/{mbox,mmdf}.5 \ > + || ewarn "failed to remove files, please file a bug" > + fi > + > + dodoc COPYRIGHT ChangeLog.md OPS* README* > +} > -- > 2.13.0 > > > -- > Nicolas Bock -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] [PATCH 0/2] vim-spell.eclass: improvements.
Hi everyone I'm working on solving https://bugs.gentoo.org/469414 but realised much of the eclass documentation isn't up to our standards. Here's a few commits to fix that oversight. Please review. Thanks! Patrice Clement (2): vim-spell.eclass: document functions using Gentoo documentation tags. vim-spell.eclass: document variables using Gentoo documentation tags. eclass/vim-spell.eclass | 66 ++--- 1 file changed, 41 insertions(+), 25 deletions(-) -- 2.13.0
[gentoo-dev] [PATCH 1/2] vim-spell.eclass: document functions using Gentoo documentation tags.
--- eclass/vim-spell.eclass | 29 ++--- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/eclass/vim-spell.eclass b/eclass/vim-spell.eclass index 0a3ef952a87..1b0f93c264d 100644 --- a/eclass/vim-spell.eclass +++ b/eclass/vim-spell.eclass @@ -1,12 +1,13 @@ -# Copyright 1999-2011 Gentoo Foundation +# Copyright 1999-2017 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# -# Original Author: Ciaran McCreesh -# Maintainers: Vim Herd -# Purpose: Simplify installing spell files for vim7 -# - +# @ECLASS: vim-spell.eclass +# @MAINTAINER: +# Vim Maintainers +# @AUTHOR: +# Ciaran McCreesh +# @BLURB: Eclass for managing Vim spell files. +# @DESCRIPTION: # How to make a vim spell file package using prebuilt spell lists # from upstream (${CODE} is the language's two letter code): # @@ -21,9 +22,9 @@ # # * Upload the tarball to the Gentoo mirrors. # -# * (for now) Add your spell file to package.mask next to the other vim7 -# things. The vim herd will handle unmasking your spell packages when vim7 -# comes out of package.mask. +# * Add your spell file to package.mask next to the other vim things. Vim +# Project members will handle unmasking your spell packages when vim comes out +# of package.mask. # # * Create the app-vim/vim-spell-${CODE} package. You should base your ebuild # upon app-vim/vim-spell-en. You will need to change VIM_SPELL_LANGUAGE, @@ -52,7 +53,7 @@ # Don't forget to update your package as necessary. # # If there isn't an upstream-provided pregenerated spell file for your language -# yet, read :help spell.txt from inside vim7 for instructions on how to create +# yet, read :help spell.txt from inside vim for instructions on how to create # spell files. It's best to let upstream know if you've generated spell files # for another language rather than keeping them Gentoo-specific. @@ -77,6 +78,9 @@ if [[ -z "${HOMEPAGE}" ]] ; then HOMEPAGE="http://www.vim.org/"; fi +# @FUNCTION: vim-spell_src_install +# @DESCRIPTION: +# Install Vim spell files. vim-spell_src_install() { target="/usr/share/vim/vimfiles/spell/" dodir "${target}" @@ -103,6 +107,9 @@ vim-spell_src_install() { [[ -z "${had_spell_file}" ]] && die "Didn't install any spell files?" } +# @FUNCTION: vim-spell_pkg_postinst +# @DESCRIPTION: +# Display installed Vim spell files. vim-spell_pkg_postinst() { has "${EAPI:-0}" 0 1 2 && ! use prefix && EROOT="${ROOT}" target="/usr/share/vim/vimfiles/spell/" -- 2.13.0
[gentoo-dev] [PATCH 2/2] vim-spell.eclass: document variables using Gentoo documentation tags.
--- eclass/vim-spell.eclass | 37 +++-- 1 file changed, 23 insertions(+), 14 deletions(-) diff --git a/eclass/vim-spell.eclass b/eclass/vim-spell.eclass index 1b0f93c264d..8c1b6314ed8 100644 --- a/eclass/vim-spell.eclass +++ b/eclass/vim-spell.eclass @@ -68,23 +68,34 @@ RDEPEND="${DEPEND}" SRC_URI="mirror://gentoo/${P}.tar.bz2" SLOT="0" -if [[ -z "${VIM_SPELL_CODE}" ]] ; then - VIM_SPELL_CODE="${PN/vim-spell-/}" -fi +# @ECLASS-VARIABLE: DESCRIPTION +# @DESCRIPTION: +# Default DESCRIPTION for Vim spell ebuilds. +: ${DESCRIPTION:="vim spell files: ${VIM_SPELL_LANGUAGE} (${VIM_SPELL_LOCALE})"} -DESCRIPTION="vim spell files: ${VIM_SPELL_LANGUAGE} (${VIM_SPELL_CODE})" +# @ECLASS-VARIABLE: HOMEPAGE +# @DESCRIPTION: +# Default HOMEPAGE for Vim spell ebuilds. +: ${HOMEPAGE:="https://www.vim.org"} -if [[ -z "${HOMEPAGE}" ]] ; then - HOMEPAGE="http://www.vim.org/"; -fi +# @ECLASS-VARIABLE: VIM_SPELL_LOCALE +# @INTERNAL +# @DESCRIPTION: +# Locale for the current ebuild. +: ${VIM_SPELL_LOCALE:="${PN/vim-spell-/}"} + +# @ECLASS-VARIABLE: VIM_SPELL_DIRECTORY +# @INTERNAL +# @DESCRIPTION: +# Path to Vim spell directory files. +: ${VIM_SPELL_DIRECTORY:="/usr/share/vim/vimfiles/spell/"} # @FUNCTION: vim-spell_src_install # @DESCRIPTION: # Install Vim spell files. vim-spell_src_install() { - target="/usr/share/vim/vimfiles/spell/" - dodir "${target}" - insinto "${target}" + dodir "${VIM_SPELL_DIRECTORY}" + insinto "${VIM_SPELL_DIRECTORY}" had_spell_file= for f in *.spl ; do @@ -112,15 +123,13 @@ vim-spell_src_install() { # Display installed Vim spell files. vim-spell_pkg_postinst() { has "${EAPI:-0}" 0 1 2 && ! use prefix && EROOT="${ROOT}" - target="/usr/share/vim/vimfiles/spell/" echo elog "To enable ${VIM_SPELL_LANGUAGE} spell checking, use" - elog ":setlocal spell spelllang=${VIM_SPELL_CODE}" + elog ":setlocal spell spelllang=${VIM_SPELL_LOCALE}" echo elog "The following (Vim internal, not file) encodings are supported for" elog "this language:" - for f in "${EROOT}/${target}/${VIM_SPELL_CODE}".*.spl ; do - enc="${f##*/${VIM_SPELL_CODE}.}" + for f in "${EROOT}/${VIM_SPELL_DIRECTORY}/${VIM_SPELL_LOCALE}".*.spl ; do enc="${f##*/${VIM_SPELL_LOCALE}.}" enc="${enc%.spl}" [[ -z "${enc}" ]] && continue elog "${enc}" -- 2.13.0
Re: [gentoo-dev] [PATCH] eutils.eclass: Document optfeature suggests packages not installed
Hi Chris Sunday 03 Sep 2017 16:56:08, Chris Mayo wrote : > --- > Please consider this clarification of optfeature. > > Chris > > eclass/eutils.eclass | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass > index fe4339f6b89..f35fa5980d7 100644 > --- a/eclass/eutils.eclass > +++ b/eclass/eutils.eclass > @@ -827,8 +827,8 @@ use_if_iuse() { > # @FUNCTION: optfeature > # @USAGE: [other atoms] > # @DESCRIPTION: > -# Print out a message suggesting an optional package (or packages) which > -# provide the described functionality > +# Print out a message suggesting an optional package (or packages) > +# not currently installed which provides the described functionality. > # > # The following snippet would suggest app-misc/foo for optional foo support, > # app-misc/bar or app-misc/baz[bar] for optional bar support > -- > 2.13.5 > > We (Michal Gorny and I) have reviewed your patch and merged it. Thanks! -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
[gentoo-dev] [PATCH 0/3] vim-plugin.eclass: improvements.
Hi I have put together a few patches to improve the state of the vim-plugin eclass. One commit solves a long standing bug. Please review. Thanks! Patrice Clement (3): vim-plugin.eclass: dohtml is now obsolete. vim-plugin.eclass: use Portage internal variables. vim-plugin.eclass: rework if else clause and reduce find calls down to one. eclass/vim-plugin.eclass | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) -- 2.13.6
[gentoo-dev] [PATCH 2/3] vim-plugin.eclass: use Portage internal variables.
Closes: https://bugs.gentoo.org/469400 --- eclass/vim-plugin.eclass | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/eclass/vim-plugin.eclass b/eclass/vim-plugin.eclass index a05cdb4520b..3c809768cf8 100644 --- a/eclass/vim-plugin.eclass +++ b/eclass/vim-plugin.eclass @@ -39,11 +39,11 @@ vim-plugin_src_install() { ebegin "Fixing file permissions" # Make sure perms are good chmod -R a+rX "${S}" || die "chmod failed" - find "${S}" -user 'portage' -exec chown root '{}' \; || die "chown failed" + find "${S}" -user "${PORTAGE_USERNAME}" -exec chown root '{}' \; || die "chown failed" if use userland_BSD || [[ ${CHOST} == *-darwin* ]] ; then - find "${S}" -group 'portage' -exec chgrp wheel '{}' \; || die "chgrp failed" + find "${S}" -group "${PORTAGE_GRPNAME}" -exec chgrp wheel '{}' \; || die "chgrp failed" else - find "${S}" -group 'portage' -exec chgrp root '{}' \; || die "chgrp failed" + find "${S}" -group "${PORTAGE_GRPNAME}" -exec chgrp root '{}' \; || die "chgrp failed" fi eend $? fi -- 2.13.6
[gentoo-dev] [PATCH 1/3] vim-plugin.eclass: dohtml is now obsolete.
--- eclass/vim-plugin.eclass | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/eclass/vim-plugin.eclass b/eclass/vim-plugin.eclass index abe9c7b3661..a05cdb4520b 100644 --- a/eclass/vim-plugin.eclass +++ b/eclass/vim-plugin.eclass @@ -71,11 +71,7 @@ vim-plugin_src_install() { local f for f in *; do [[ -f "${f}" ]] || continue - if [[ "${f}" = *.html ]]; then - dohtml "${f}" - else - dodoc "${f}" - fi + dodoc "${f}" rm "${f}" || die done -- 2.13.6
[gentoo-dev] [PATCH 3/3] vim-plugin.eclass: rework if else clause and reduce find calls down to one.
--- eclass/vim-plugin.eclass | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/eclass/vim-plugin.eclass b/eclass/vim-plugin.eclass index 3c809768cf8..d635a2aa436 100644 --- a/eclass/vim-plugin.eclass +++ b/eclass/vim-plugin.eclass @@ -40,11 +40,11 @@ vim-plugin_src_install() { # Make sure perms are good chmod -R a+rX "${S}" || die "chmod failed" find "${S}" -user "${PORTAGE_USERNAME}" -exec chown root '{}' \; || die "chown failed" + local _grp="root" if use userland_BSD || [[ ${CHOST} == *-darwin* ]] ; then - find "${S}" -group "${PORTAGE_GRPNAME}" -exec chgrp wheel '{}' \; || die "chgrp failed" - else - find "${S}" -group "${PORTAGE_GRPNAME}" -exec chgrp root '{}' \; || die "chgrp failed" + _grp="wheel" fi + find "${S}" -group "${PORTAGE_GRPNAME}" -exec chgrp "${_grp}" '{}' \; || die "chgrp failed" eend $? fi -- 2.13.6
Re: [gentoo-dev] [PATCH 2/3] vim-plugin.eclass: use Portage internal variables.
Sunday 05 Nov 2017 00:26:33, Michał Górny wrote : > W dniu sob, 04.11.2017 o godzinie 22∶48 +0100, użytkownik Patrice > Clement napisał: > > Closes: https://bugs.gentoo.org/469400 > > --- > > eclass/vim-plugin.eclass | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/eclass/vim-plugin.eclass b/eclass/vim-plugin.eclass > > index a05cdb4520b..3c809768cf8 100644 > > --- a/eclass/vim-plugin.eclass > > +++ b/eclass/vim-plugin.eclass > > @@ -39,11 +39,11 @@ vim-plugin_src_install() { > > ebegin "Fixing file permissions" > > # Make sure perms are good > > chmod -R a+rX "${S}" || die "chmod failed" > > - find "${S}" -user 'portage' -exec chown root '{}' \; || die > > "chown failed" > > + find "${S}" -user "${PORTAGE_USERNAME}" -exec chown root '{}' > > \; || die "chown failed" > > if use userland_BSD || [[ ${CHOST} == *-darwin* ]] ; then > > - find "${S}" -group 'portage' -exec chgrp wheel '{}' \; > > || die "chgrp failed" > > + find "${S}" -group "${PORTAGE_GRPNAME}" -exec chgrp > > wheel '{}' \; || die "chgrp failed" > > else > > - find "${S}" -group 'portage' -exec chgrp root '{}' \; > > || die "chgrp failed" > > + find "${S}" -group "${PORTAGE_GRPNAME}" -exec chgrp > > root '{}' \; || die "chgrp failed" > > fi > > eend $? > > fi > > This is going to die on every non-Portage package manager. > > -- > Best regards, > Michał Górny > > Michal, Ulrich, ACK. This code has been there for ages and I also don't think it makes sense to keep it as it seems these operations are handled by Portage already. Mike (floppym) suggested to remove the whole if clause and call fperms instead: diff --git a/eclass/vim-plugin.eclass b/eclass/vim-plugin.eclass index abe9c7b3661..46908bb73e6 100644 --- a/eclass/vim-plugin.eclass +++ b/eclass/vim-plugin.eclass @@ -35,19 +35,6 @@ vim-plugin_src_install() { has "${EAPI:-0}" 0 1 2 && ! use prefix && ED="${D}" local f - if use !prefix && [[ ${EUID} -eq 0 ]] ; then - ebegin "Fixing file permissions" - # Make sure perms are good - chmod -R a+rX "${S}" || die "chmod failed" - find "${S}" -user 'portage' -exec chown root '{}' \; || die "chown failed" - if use userland_BSD || [[ ${CHOST} == *-darwin* ]] ; then - find "${S}" -group 'portage' -exec chgrp wheel '{}' \; || die "chgrp failed" - else - find "${S}" -group 'portage' -exec chgrp root '{}' \; || die "chgrp failed" - fi - eend $? - fi - # When globbing, if nothing exists, the shell literally returns the glob # pattern. So turn on nullglob and extglob options to avoid this. eshopts_push -s extglob @@ -86,7 +73,7 @@ vim-plugin_src_install() { "couldn't move ${S} to ${ED}/usr/share/vim/vimfiles" # Fix remaining bad permissions - chmod -R -x+X "${ED}"/usr/share/vim/vimfiles/ || die "chmod failed" + fperms -R a+rX /usr/share/vim/vimfiles } Please let me know what you guys think. -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
[gentoo-dev] [gentoo-dev-announce] Last-rites: app-vim/pam-syntax
# Patrice Clement (19 Dec 2017) # A slightly better syntax file for PAM configuration files is shipped with Vim # since version 8.0. The one we package is old and out of date. # Masked for removal in 30 days. See bug 578278. app-vim/pam-syntax -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
Re: [gentoo-dev] Projects up for grabs: cron, m68k
Wednesday 20 Dec 2017 12:49:18, Anthony G. Basile wrote : > On 12/20/17 12:07 PM, Anthony G. Basile wrote: > > On 12/20/17 12:02 PM, Michał Górny wrote: > >> Hello, everyone. > >> > >> Due to prolonged inactivity of Mike Frysinger (vapier), the following > >> projects have had effectively no members for 6 months already: > >> > >> https://wiki.gentoo.org/wiki/Project:Cron > >> > >> sys-process/anacron [m] > >> sys-process/at > >> sys-process/bcron > >> sys-process/cronbase > >> sys-process/cronie [m] > >> sys-process/dcron > >> sys-process/fcron [m] > >> sys-process/vixie-cron > >> virtual/cron > >> > >> https://wiki.gentoo.org/wiki/Project:M68k > >> > >> sys-apps/zorroutils [m] > >> sys-fs/atari-fdisk > >> > >> The packages listed with '[m]' have other maintainers. The remaining > >> packages are solely maintained by the listed projects. > >> > >> If you are interested in helping out with some of those packages, please > >> consider joining the appropriate project and/or co-maintaining the > >> individual packages. > >> > >> If the projects see no activity within the next month, I will disband > >> them and move the appropriate packages to maintainer-needed. > >> > > > > Those are very important packages. I use fcron and at and I can help > > take care of those. I should probably take a look a t cronbase and > > virtual/cron too. > > > > Okay a followup on my last email, I added myself to the project and will > try to take care of all cron packages. > > -- > Anthony G. Basile, Ph.D. > Gentoo Linux Developer [Hardened] > E-Mail: bluen...@gentoo.org > GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA > GnuPG ID : F52D4BBA > Hi there We use fcron a lot at ${work} so I've also added myself to the project in an attempt to help out with fcron-related bugs. Cheers -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
+../../../../../../../features/prefix/standalone/beyond-kernel-2.6.32 > diff --git > a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi > b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi > new file mode 100644 > index ..7ed6ff82de6b > --- /dev/null > +++ > b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi > @@ -0,0 +1 @@ > +5 > diff --git > a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent > > b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent > new file mode 100644 > index ..b3da232ba558 > --- /dev/null > +++ > b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent > @@ -0,0 +1,2 @@ > +.. > +../../../../../../../features/prefix/standalone > diff --git a/profiles/default/linux/amd64/17.0/no-multilib/prefix/parent > b/profiles/default/linux/amd64/17.0/no-multilib/prefix/parent > new file mode 100644 > index ..f3229c5b9876 > --- /dev/null > +++ b/profiles/default/linux/amd64/17.0/no-multilib/prefix/parent > @@ -0,0 +1 @@ > +.. > diff --git a/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi > b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi > new file mode 100644 > index ..7ed6ff82de6b > --- /dev/null > +++ b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi > @@ -0,0 +1 @@ > +5 > diff --git > a/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent > b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent > new file mode 100644 > index ..4372cb6f5834 > --- /dev/null > +++ b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent > @@ -0,0 +1,2 @@ > +.. > +../../../../../../features/prefix/standalone/beyond-kernel-2.6.16 > diff --git a/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi > b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi > new file mode 100644 > index ..7ed6ff82de6b > --- /dev/null > +++ b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi > @@ -0,0 +1 @@ > +5 > diff --git > a/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent > b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent > new file mode 100644 > index ..ee208c413bf2 > --- /dev/null > +++ b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent > @@ -0,0 +1,2 @@ > +.. > +../../../../../../features/prefix/standalone/beyond-kernel-2.6.32 > diff --git a/profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi > b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi > new file mode 100644 > index ..7ed6ff82de6b > --- /dev/null > +++ b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi > @@ -0,0 +1 @@ > +5 > diff --git a/profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent > b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent > new file mode 100644 > index ..b8a505e58f6c > --- /dev/null > +++ b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent > @@ -0,0 +1,2 @@ > +.. > +../../../../../../features/prefix/standalone > diff --git a/profiles/default/linux/x86/17.0/prefix/parent > b/profiles/default/linux/x86/17.0/prefix/parent > new file mode 100644 > index ..f3229c5b9876 > --- /dev/null > +++ b/profiles/default/linux/x86/17.0/prefix/parent > @@ -0,0 +1 @@ > +.. > diff --git a/profiles/profiles.desc b/profiles/profiles.desc > index 2812791936cc..e0683269cc11 100644 > --- a/profiles/profiles.desc > +++ b/profiles/profiles.desc > @@ -334,8 +334,14 @@ x86-linuxprefix/linux/x86 > exp > # Linux Standalone Profiles > amd64-linux prefix/linux-standalone/amd64 exp > amd64-linux prefix/linux-standalone/amd64/legacyexp > +amd64-linux > default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2 exp > +amd64-linux > default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32exp > +amd64-linux > default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16exp > x86-linuxprefix/linux-standalone/x86 exp > x86-linuxprefix/linux-standalone/x86/legacy exp > +x86-linuxdefault/linux/x86/17.0/prefix/beyond-kernel-3.2 > exp > +x86-linuxdefault/linux/x86/17.0/prefix/beyond-kernel-2.6.32 > exp > +x86-linuxdefault/linux/x86/17.0/prefix/beyond-kernel-2.6.16 > exp > arm-linuxprefix/linux-standalone/arm/armv7a exp > arm64-linux prefix/linux-standalone/arm64 exp > ppc64-linux prefix/linux-standalone/ppc64 exp > -- > 2.15.1 > Thanks for the work. Could you also consider adding a Prefix profile compatible with FreeBSD? Best, -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
Re: [gentoo-dev] about commits in the future
Hi Fabian Every now and then, my commits get rejected from the Gentoo Git server with an error saying that my clock is behind and that I need to rewind it. I then run the command `ntpdate europe.pool.ntp.org' to get my clock synced. Eventually, I rebase my latest commits with git and push to the repo. Something might have gone wrong during the clock sync and git rebase? I'm not too sure. Thanks for pointing out this oddity though! Wednesday 21 Feb 2018 09:47:29, Fabian Groffen wrote : > Please consider commit 2fb923d758749be609c1daab2a72ad4f1ec4c2a9 > (use something like >git log --pretty=fuller app-emulation/nemu/nemu-1.4.0.ebuild) > > It was made roughly one day in the future. I'm wondering: > 1) is this bad at all? > 2) if it is bad (got me confused for another reason) is it technically >possible to reject such commits? > 3) if 2) should we decide on some clock skew and reject anything which >is beyond that? > > How do others feel about this? > > Thanks, > Fabian > > -- > Fabian Groffen > Gentoo on a different level -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] details on the PMS
Hi Michael Saturday 24 Feb 2018 02:48:02, Michael Lienhardt wrote : > I noticed that the following files are not mentioned, or stated optional in > the PMS: > - profiles/repo_name > - metadata/layout.conf > > It seems to me that without these files, portage complains. Shouldn't them be > declared as mandatory? > > - profiles/package.use and profiles/make.defaults > (https://wiki.gentoo.org/wiki/USE_ORDER) > These files are not documented in the PMS: should the package manager > recognize these files? (if so, I think it would be clearer to document them > in the PMS) > > Also, in https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-430004.7.1 the > directory is named metadata/cache while it is named metadata/md5-cache in my > repository. > > > Should I report something on the Gentoo Bugzilla? > > Best, > Michael Lienhardt > Please do. If the documentation is lacking for these files, it must be fixed ASAP. Thanks for picking this up! -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
[gentoo-dev] Packages up for grabs
Hi gents The following packages are up for grabs: app-benchmarks/stress-ng app-cdr/cdrdao app-i18n/ibus-cangjie app-i18n/libcangjie dev-python/cangjie dev-embedded/libftd2xx media-sound/fmit net-misc/redir net-misc/s3cmd net-misc/ser2net sci-electronics/quartus-prime-lite sys-apps/intel-performance-counter-monitor sys-apps/likwid Best, -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [PATCH] ant-tasks.eclass: use eapi7-ver
Tuesday 22 May 2018 13:28:50, Ulrich Mueller wrote : > >>>>> On Tue, 22 May 2018, Marty E Plummer wrote: > > > How's this? > > --- > > eclass/ant-tasks.eclass | 11 ++- > > 1 file changed, 6 insertions(+), 5 deletions(-) > > > diff --git a/eclass/ant-tasks.eclass b/eclass/ant-tasks.eclass > > index e008e6eaea8..31683e68243 100644 > > --- a/eclass/ant-tasks.eclass > > +++ b/eclass/ant-tasks.eclass > > @@ -16,7 +16,8 @@ > > JAVA_ANT_DISABLE_ANT_CORE_DEP=true > > # rewriting build.xml for are the testcases has no reason atm > > JAVA_PKG_BSFIX_ALL=no > > -inherit versionator java-pkg-2 java-ant-2 > > +inherit java-pkg-2 java-ant-2 > > +[[ ${EAPI:-0} == [0123456] ]] && inherit eapi7-ver > > > EXPORT_FUNCTIONS src_unpack src_compile src_install > > > @@ -60,12 +61,12 @@ if [[ ${PV} == *beta2* ]]; then > > MY_PV=${PV/_beta2/beta} > > UPSTREAM_PREFIX="http://people.apache.org/dist/ant/v1.7.1beta2/src"; > > GENTOO_PREFIX="https://dev.gentoo.org/~caster/distfiles"; > > - ANT_TASK_PV=$(get_version_component_range 1-3) > > + ANT_TASK_PV=$(ver_cut 1-3) > > elif [[ ${PV} == *_rc* ]]; then > > MY_PV=${PV/_rc/RC} > > UPSTREAM_PREFIX="https://dev.gentoo.org/~caster/distfiles"; > > GENTOO_PREFIX="https://dev.gentoo.org/~caster/distfiles"; > > - ANT_TASK_PV=$(get_version_component_range 1-3) > > + ANT_TASK_PV=$(ver_cut 1-3) > > else > > # default for final releases > > MY_PV=${PV} > > @@ -101,7 +102,7 @@ if [[ -z "${ANT_TASK_DISABLE_VM_DEPS}" ]]; then > > fi > > > # we need direct blockers with old ant-tasks for file collisions - bug > > #252324 > > -if version_is_at_least 1.7.1 ; then > > +if ver_test -ge 1.7.1; then > > DEPEND+=" !dev-java/ant-tasks" > > fi > > > @@ -167,7 +168,7 @@ ant-tasks_src_install() { > > java-pkg_register-ant-task --version "${ANT_TASK_PV}" > > > # create the compatibility symlink > > - if version_is_at_least 1.7.1_beta2; then > > + if ver_test -ge 1.7.1_beta2; then > > dodir /usr/share/ant/lib > > dosym /usr/share/${PN}/lib/${PN}.jar > > /usr/share/ant/lib/${PN}.jar > > fi > > -- > > 2.17.0 > > LGTM Thanks Marty and Ulrich. LGTM too. I'm going to merge this patch. -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] [gentoo-dev-announce] Last rites: dev-java/{echo2,zemberek}.
# Patrice Clement (17 Mar 2019) # Old and unmaintained Java libraries. Removal in 30 days. dev-java/zemberek dev-java/echo2 -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] [gentoo-dev-announce] Last rites: dev-java/[...], media-sound/jtagger, app-admin/389-console Reply-To:
# Patrice Clement (14 Apr 2019) # Old, unmaintained and sometimes abandoned Java libraries/programs. # Removal in 30 days. dev-java/idm-console-framework dev-java/matrix-toolkits-java dev-java/sat4j-pseudo dev-java/sat4j-core dev-java/swarmcache dev-java/dbus-java dev-java/jinklevel dev-java/proguard dev-java/nailgun dev-java/jgroups dev-java/libmso dev-java/jicmp media-sound/jtagger app-admin/389-console -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] [gentoo-dev-announce] Last rites: media-tv/tvbrowser
# Patrice Clement (06 May 2019) # Broken build. Outdated version. No interest from the Java team to maintain # it. Removal in 30 days. Bug #581720. media-tv/tvbrowser -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs due to nimiux's retirement
Monday 20 May 2019 17:53:52, Michał Górny wrote : > Hello, > > The following packages are now up for grabs: > > [...] > app-misc/vifm > I'm taking over this one. -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] [gentoo-dev-announce] Package up for grabs: net-im/mattermost-desktop-bin
Hi net-im/mattermost-desktop-bin is now up for grabs. Thanks. -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
[gentoo-dev] [gentoo-dev-announce] Last rites: net-irc/irssi-otr
# Patrice Clement (2019-10-02) # OTR support is fully integrated within irssi since version 1.2.0. Type /help otr # at the command prompt to find out more. The OTR module is therefore obsolete # and can be tree-cleaned. # Masked for removal in 30 days. Bug #696074. net-irc/irssi-otr -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Package up for grabs: net-misc/mosh
The following package is now up for grabs: net-misc/mosh -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
[gentoo-dev] [gentoo-dev-announce] Package up for grabs: app-office/calcurse
The following package is now up for grabs: app-office/calcurse It needs a bit of care and I don't have time to maintain it properly. See #712126. -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Add commit to pull request
Hi Samuel No you don't have to file a new PR. Basically, you have to: * commit your code against the branch. At that point, there are two commits (or more if you commit multiple times) in your branch, or PR if we talk in GH jargon. * squash that commit into the previous commit so as to get a single commit. * force push against said branch: git push -f origin your-awesome-pr. That's about it. This article sums up the process pretty well: https://www.devroom.io/2011/07/05/git-squash-your-latests-commits-into-one/ Cheers, Sunday 21 Jun 2020 17:48:14, Samuel Bernardo wrote : > Hi, > > I need to add a commit to a gentoo pull request that I had opened before. > > https://github.com/samuelbernardo/gentoo > > Is it possible to add the commit to that pull request or I need to open > a new pull request? > > I already try to get help in gentoo-dev channel but I haven't voice there... > > Thanks > >
[gentoo-dev] [PATCH] eclass/vim-plugin.eclass: delete if has_version condition.
... and replace it with a test against the REPLACING_VERSIONS variable. See https://projects.gentoo.org/pms/8/pms.html#x1-10900011.1. Patch courtesy of Arfrever. Closes: https://github.com/gentoo/gentoo/pull/21733 Signed-off-by: Patrice Clement --- eclass/vim-plugin.eclass | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/eclass/vim-plugin.eclass b/eclass/vim-plugin.eclass index 6b72d66111d..460edcce3eb 100644 --- a/eclass/vim-plugin.eclass +++ b/eclass/vim-plugin.eclass @@ -126,31 +126,31 @@ update_vim_afterscripts() { display_vim_plugin_help() { local h - if ! has_version ${CATEGORY}/${PN} ; then - if [[ -n "${VIM_PLUGIN_HELPFILES}" ]] ; then + if [[ -z ${REPLACING_VERSIONS} ]]; then + if [[ -n "${VIM_PLUGIN_HELPFILES}" ]]; then elog " " elog "This plugin provides documentation via vim's help system. To" elog "view it, use:" - for h in ${VIM_PLUGIN_HELPFILES} ; do + for h in ${VIM_PLUGIN_HELPFILES}; do elog ":help ${h}" done elog " " - elif [[ -n "${VIM_PLUGIN_HELPTEXT}" ]] ; then + elif [[ -n "${VIM_PLUGIN_HELPTEXT}" ]]; then elog " " while read h ; do elog "$h" done <<<"${VIM_PLUGIN_HELPTEXT}" elog " " - elif [[ -n "${VIM_PLUGIN_HELPURI}" ]] ; then + elif [[ -n "${VIM_PLUGIN_HELPURI}" ]]; then elog " " elog "Documentation for this plugin is available online at:" elog "${VIM_PLUGIN_HELPURI}" elog " " fi - if has "filetype" "${VIM_PLUGIN_MESSAGES}" ; then + if has "filetype" "${VIM_PLUGIN_MESSAGES}"; then elog "This plugin makes use of filetype settings. To enable these," elog "add lines like:" elog "filetype plugin on" -- 2.31.1
Re: [gentoo-dev] [PATCH] eclass/vim-plugin.eclass: delete if has_version condition.
Wednesday 21 Jul 2021 19:16:36, Ulrich Mueller wrote : > >>>>> On Wed, 21 Jul 2021, Patrice Clement wrote: > > > + if [[ -n "${VIM_PLUGIN_HELPFILES}" ]]; then > > Quotation marks are not necessary here (and three more times below, > in the elif lines). Thanks, this has been mended.
Re: [gentoo-dev] [PATCH] eclass/vim-plugin.eclass: delete if has_version condition.
Thursday 22 Jul 2021 04:44:39, Sam James wrote : > > > > On 21 Jul 2021, at 17:47, Patrice Clement wrote: > > > > ... and replace it with a test against the REPLACING_VERSIONS variable. > > > > See https://projects.gentoo.org/pms/8/pms.html#x1-10900011.1. > > > > Patch courtesy of Arfrever. > > > > Ideally, we'd use Arfrever's sign off, but this is kind of a grey > area, so it's not a blocker at all right now. > > > Closes: https://github.com/gentoo/gentoo/pull/21733 > > Signed-off-by: Patrice Clement > > --- > > eclass/vim-plugin.eclass | 12 ++-- > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > diff --git a/eclass/vim-plugin.eclass b/eclass/vim-plugin.eclass > > index 6b72d66111d..460edcce3eb 100644 > > --- a/eclass/vim-plugin.eclass > > +++ b/eclass/vim-plugin.eclass > > [snip] > > The patch itself seems fine, but I have some suggestions while we're > working on the eclass: > > - Add EAPI 8 support > > - Please drop obsolete EAPI compatibility hacks like: > >has "${EAPI:-0}" 0 1 2 && ! use prefix && ED="${D}" > > This is unnecessary because we're only declaring support for EAPI 6 and 7 > right now. > > - Could you please convert POSIX tests to Bash tests? [0] > > - In update_vim_afterscripts, the einfo seems (at first glance) to be > misleading. Should > it be printing ${afterdir} instead? > > - Ideally, we'd add the standard inherit guard if possible (see e.g. > gnuconfig.eclass for a simple example). > > [0] > https://devmanual.gentoo.org/tools-reference/bash/#single-versus-double-brackets-in-bash > > Let me know if you need any assistance, etc. > > thanks, > sam > > > > Thanks for the suggestions. If you don't mind, I'd like to stick to the original changes for now and address your suggestions later in a follow up patch. Best,
[gentoo-dev] [PATCH] eclass/vim-plugin.eclass: delete if has_version condition.
... and replace it with a test against the REPLACING_VERSIONS variable. See https://projects.gentoo.org/pms/8/pms.html#x1-10900011.1. This is an updated version of the same patch discussed previously on this ML. Suggested by Arfrever. --- eclass/vim-plugin.eclass | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/eclass/vim-plugin.eclass b/eclass/vim-plugin.eclass index 6b72d66111d..460edcce3eb 100644 --- a/eclass/vim-plugin.eclass +++ b/eclass/vim-plugin.eclass @@ -126,31 +126,31 @@ update_vim_afterscripts() { display_vim_plugin_help() { local h - if ! has_version ${CATEGORY}/${PN} ; then - if [[ -n "${VIM_PLUGIN_HELPFILES}" ]] ; then + if [[ -z ${REPLACING_VERSIONS} ]]; then + if [[ -n ${VIM_PLUGIN_HELPFILES} ]]; then elog " " elog "This plugin provides documentation via vim's help system. To" elog "view it, use:" - for h in ${VIM_PLUGIN_HELPFILES} ; do + for h in ${VIM_PLUGIN_HELPFILES}; do elog ":help ${h}" done elog " " - elif [[ -n "${VIM_PLUGIN_HELPTEXT}" ]] ; then + elif [[ -n ${VIM_PLUGIN_HELPTEXT} ]]; then elog " " while read h ; do elog "$h" done <<<"${VIM_PLUGIN_HELPTEXT}" elog " " - elif [[ -n "${VIM_PLUGIN_HELPURI}" ]] ; then + elif [[ -n ${VIM_PLUGIN_HELPURI} ]]; then elog " " elog "Documentation for this plugin is available online at:" elog "${VIM_PLUGIN_HELPURI}" elog " " fi - if has "filetype" "${VIM_PLUGIN_MESSAGES}" ; then + if has filetype ${VIM_PLUGIN_MESSAGES}; then elog "This plugin makes use of filetype settings. To enable these," elog "add lines like:" elog "filetype plugin on" -- 2.31.1