Re: [aur-general] Promoting use of .AURINFO
I don't fully understand the logic in currently having an .AURINFO instead of defining the .SRCINFO format right now and have a tool generating those for the time being (since it'll likely be the same format as .PKGINFO). It can go in makepkg later. J. Leclanche On Sun, Jan 12, 2014 at 11:12 PM, Lukas Fleischer wrote: > On Sun, 12 Jan 2014 at 23:49:39, Justin Dray wrote: >> [...] >> It might also be a good idea to write out what fields are available and >> their purpose on the wiki similar to the PKGBUILD page ( >> https://wiki.archlinux.org/index.php/PKGBUILD) and perhaps link to it from >> the AUR user guidelines page? It will be forgotten by most packagers if the >> only information about it is a commit message and a mailing list thread. > > That is what I suggested in the initial mail. > >> >> Regards, >> Justin Dray >> E: jus...@dray.be >> M: 0433348284
Re: [aur-general] Promoting use of .AURINFO
On Sun, 12 Jan 2014 at 23:49:39, Justin Dray wrote: > [...] > It might also be a good idea to write out what fields are available and > their purpose on the wiki similar to the PKGBUILD page ( > https://wiki.archlinux.org/index.php/PKGBUILD) and perhaps link to it from > the AUR user guidelines page? It will be forgotten by most packagers if the > only information about it is a commit message and a mailing list thread. That is what I suggested in the initial mail. > > Regards, > Justin Dray > E: jus...@dray.be > M: 0433348284
Re: [aur-general] Promoting use of .AURINFO
On Sun, 12 Jan 2014 at 21:17:29, Jerome Leclanche wrote: > [...] > So the official goal is to have it generated as part of makepkg -S? Yes, but the requirements for makepkg(8) inclusion are much higher than what we need for the AUR and it doesn't look like there is someone who wants to deal with them right now. > Because I see that as the only way the format will get popular: if > it's nobody's problem. So having to invoke `makepkg --source && addaurinfo` instead of the usual `makepkg --source` is a problem? And it still is a problem if you add a line like alias mkaurpkg='makepkg --source && addaurinfo' to your shell rc file and use `mkaurpkg` to build AUR packages (the names are all made up)? Sorry, but that's nonsense. The current AUR PKGBUILD parser is a dead-end. We have several bug reports and adding more workarounds makes no sense at this point. Also, having some kind of metadata makes some of our future plans easier to implement. Why should we refuse to switch to a system that is much cleaner and (almost) just as convenient as the former method? > > J. Leclanche > [...]
Re: [aur-general] Promoting use of .AURINFO
On Mon, Jan 13, 2014 at 6:17 AM, Jerome Leclanche wrote: > On Sun, Jan 12, 2014 at 3:11 PM, Lukas Fleischer > wrote: > > On Sun, 12 Jan 2014 at 15:51:48, Anton Larionov wrote: > >> Hello, > >> > >> I was under the impression that .AURINFO was introduced to override some > >> fields in PKGBUILD when they are written in format which can't be > properly > >> displayed by AUR (or maybe I've missed something). But why do you want > to > >> force it's usage for all packages? In most cases AURINFO will just > >> duplicate same fields from PKGBUILD. > > > > The long-term plan is to use it for all AUR packages, improve the format > > and finally make it an official feature of makepkg(8) (the file will > > probably be called .SRCINFO then but we're far from there). See my other > > reply to Sebastien for some reasons on why it should be used. > > > > So the official goal is to have it generated as part of makepkg -S? > Because I see that as the only way the format will get popular: if > it's nobody's problem. > > J. Leclanche > > >> > >> Also I have some questions about it's format: > >> > >> 1) If package has different dependencies for 86_64 and 686, what should > I > >>put in depend array? > > > > Good question. This cannot be answered properly, though, since > > dependencies actually are a property of the binary package and not a > > property of the source package. Maybe we should loosen the format for > > dependencies of source packages and allow optdep-like comments? > > Something like: > > > > depends = foo > > depends = bar > > depends = foobar: x86_64 only > > > > Just an idea. Comments welcome. > > > >> > >> 2) Which 'pkgname' will be unique - from PKGBUILD or AURINFO? E.g if I > >>upload package with name 'foo' and overriden name 'bar' will someone > >>be able to upload new package with name 'foo'? Or 'bar'? > > > > Only the information from .AURINFO will be used. You can already trick > > the AUR into reading a completely different name from the PKGBUILD than > > it actually produces (and that problem is unavoidable), so that isn't a > > (new) issue. > > > >> > >> -- > >> > >> Regards, > >> Anton Larionov > It might also be a good idea to write out what fields are available and their purpose on the wiki similar to the PKGBUILD page ( https://wiki.archlinux.org/index.php/PKGBUILD) and perhaps link to it from the AUR user guidelines page? It will be forgotten by most packagers if the only information about it is a commit message and a mailing list thread. Regards, Justin Dray E: jus...@dray.be M: 0433348284
Re: [aur-general] Promoting use of .AURINFO
On Sun, Jan 12, 2014 at 3:11 PM, Lukas Fleischer wrote: > On Sun, 12 Jan 2014 at 15:51:48, Anton Larionov wrote: >> Hello, >> >> I was under the impression that .AURINFO was introduced to override some >> fields in PKGBUILD when they are written in format which can't be properly >> displayed by AUR (or maybe I've missed something). But why do you want to >> force it's usage for all packages? In most cases AURINFO will just >> duplicate same fields from PKGBUILD. > > The long-term plan is to use it for all AUR packages, improve the format > and finally make it an official feature of makepkg(8) (the file will > probably be called .SRCINFO then but we're far from there). See my other > reply to Sebastien for some reasons on why it should be used. > So the official goal is to have it generated as part of makepkg -S? Because I see that as the only way the format will get popular: if it's nobody's problem. J. Leclanche >> >> Also I have some questions about it's format: >> >> 1) If package has different dependencies for 86_64 and 686, what should I >>put in depend array? > > Good question. This cannot be answered properly, though, since > dependencies actually are a property of the binary package and not a > property of the source package. Maybe we should loosen the format for > dependencies of source packages and allow optdep-like comments? > Something like: > > depends = foo > depends = bar > depends = foobar: x86_64 only > > Just an idea. Comments welcome. > >> >> 2) Which 'pkgname' will be unique - from PKGBUILD or AURINFO? E.g if I >>upload package with name 'foo' and overriden name 'bar' will someone >>be able to upload new package with name 'foo'? Or 'bar'? > > Only the information from .AURINFO will be used. You can already trick > the AUR into reading a completely different name from the PKGBUILD than > it actually produces (and that problem is unavoidable), so that isn't a > (new) issue. > >> >> -- >> >> Regards, >> Anton Larionov
Re: [aur-general] Promoting use of .AURINFO
On Sun, Jan 12, 2014 at 04:11:14PM +0100, Lukas Fleischer wrote: > On Sun, 12 Jan 2014 at 15:51:48, Anton Larionov wrote: > > Hello, > > > > I was under the impression that .AURINFO was introduced to override some > > fields in PKGBUILD when they are written in format which can't be properly > > displayed by AUR (or maybe I've missed something). But why do you want to > > force it's usage for all packages? In most cases AURINFO will just > > duplicate same fields from PKGBUILD. > > The long-term plan is to use it for all AUR packages, improve the format > and finally make it an official feature of makepkg(8) (the file will > probably be called .SRCINFO then but we're far from there). See my other > reply to Sebastien for some reasons on why it should be used. > > > > > Also I have some questions about it's format: > > > > 1) If package has different dependencies for 86_64 and 686, what should I > >put in depend array? > > Good question. This cannot be answered properly, though, since > dependencies actually are a property of the binary package and not a > property of the source package. Maybe we should loosen the format for > dependencies of source packages and allow optdep-like comments? > Something like: > > depends = foo > depends = bar > depends = foobar: x86_64 only > > Just an idea. Comments welcome. > > > > > 2) Which 'pkgname' will be unique - from PKGBUILD or AURINFO? E.g if I > >upload package with name 'foo' and overriden name 'bar' will someone > >be able to upload new package with name 'foo'? Or 'bar'? > > Only the information from .AURINFO will be used. You can already trick > the AUR into reading a completely different name from the PKGBUILD than > it actually produces (and that problem is unavoidable), so that isn't a > (new) issue. I've created shell-helper which generate srcpkg, add .AURINFO and upload it. Haven't really tested it much yet. https://gist.github.com/diffycat/8389617 And I don't think that many people will start adding .AURINFO until it's creation will be supported in makepkg. Like you start `makepkg --source`, then it's search for existing .AURINFO (or .SRCINFO) or generate it from corresponding fields in pkgbuild, print it and allow to edit before packaging. -- Regards, Anton Larionov
Re: [aur-general] Can we force the maintainer to change package name?
On 12 January 2014 23:42, Karol Blazewicz wrote: > On Fri, Dec 20, 2013 at 3:41 PM, Karol Blazewicz > wrote: >> On Fri, Dec 20, 2013 at 3:19 PM, Lukas Jirkovsky >> wrote: >>> On Fri, Dec 20, 2013 at 2:24 PM, Rashif Ray Rahman >>> wrote: Since there was no 'rstudio' at the time that user uploaded this one, there is no infringement of any rule or guideline per se. Just tell them to upload an 'r-studio' to mitigate the confusion that resulted from it. I don't think there is any need to merge unless there were relevant comments. It is up to the maintainer to update the PKGBUILD with the suggested changes. >>> >>> The question is whether the maintainer is still active at all. Hist >>> last action is 2012-08-27 and he has only two packages, both over the >>> year old with one being flagged out of date since February. >>> >>> Lukas >> >> e-mail sent. >> If he doesn't respond in two weeks, maybe a TU can reupload and disown >> it, or remove it from the AUR altogether, whichever is deemed the >> correct action. > > The maintainer has taken no action and didn't respond to my e-mail. Deleted the package. I have it backed up, will keep for several weeks in case someone really wants it reuploaded. -- GPG/PGP ID: C0711BF1
Re: [aur-general] Orpan request: xgraph
On 01/12/2014 03:49 PM, Sergio Correia wrote: > Hello, > > I'd like to request the 'xgraph' [1] package to be orphaned. It > doesn't build for a few months, and I have posted an updated PKGBUILD > in the comments in Dec 7th 2013, with no answer from the maintainer. A > few days later (Dec 18th) I marked the package out-of-date and emailed > the maintainer Sven, but got no response so far, almost a month later. > > Best Regards, > Sergio > > [1] https://aur.archlinux.org/packages/xgraph/ > Orphaned, thank you. -- Bartłomiej Piotrowski http://bpiotrowski.pl/ signature.asc Description: OpenPGP digital signature
Re: [aur-general] Concern about 'weepcraft' package
On 01/12/2014 11:54 AM, Schala Zeal wrote: > I came across a package in the AUR recently updated called 'weepcraft.' > It is apparently a hacked Minecraft client, most likely intended for > malicious purposes. Additionally, Mojang states in the Minecraft product > not to redistribute the software, and the "Weepcraft" website apparently > does just that. Deleted, thanks. -- Bartłomiej Piotrowski http://bpiotrowski.pl/ signature.asc Description: OpenPGP digital signature
Re: [aur-general] Can we force the maintainer to change package name?
On Fri, Dec 20, 2013 at 3:41 PM, Karol Blazewicz wrote: > On Fri, Dec 20, 2013 at 3:19 PM, Lukas Jirkovsky > wrote: >> On Fri, Dec 20, 2013 at 2:24 PM, Rashif Ray Rahman >> wrote: >>> Since there was no 'rstudio' at the time that user uploaded this one, >>> there is no infringement of any rule or guideline per se. Just tell >>> them to upload an 'r-studio' to mitigate the confusion that resulted >>> from it. I don't think there is any need to merge unless there were >>> relevant comments. It is up to the maintainer to update the PKGBUILD >>> with the suggested changes. >> >> The question is whether the maintainer is still active at all. Hist >> last action is 2012-08-27 and he has only two packages, both over the >> year old with one being flagged out of date since February. >> >> Lukas > > e-mail sent. > If he doesn't respond in two weeks, maybe a TU can reupload and disown > it, or remove it from the AUR altogether, whichever is deemed the > correct action. The maintainer has taken no action and didn't respond to my e-mail.
Re: [aur-general] Promoting use of .AURINFO
On Sun, 12 Jan 2014 at 15:51:48, Anton Larionov wrote: > Hello, > > I was under the impression that .AURINFO was introduced to override some > fields in PKGBUILD when they are written in format which can't be properly > displayed by AUR (or maybe I've missed something). But why do you want to > force it's usage for all packages? In most cases AURINFO will just > duplicate same fields from PKGBUILD. The long-term plan is to use it for all AUR packages, improve the format and finally make it an official feature of makepkg(8) (the file will probably be called .SRCINFO then but we're far from there). See my other reply to Sebastien for some reasons on why it should be used. > > Also I have some questions about it's format: > > 1) If package has different dependencies for 86_64 and 686, what should I >put in depend array? Good question. This cannot be answered properly, though, since dependencies actually are a property of the binary package and not a property of the source package. Maybe we should loosen the format for dependencies of source packages and allow optdep-like comments? Something like: depends = foo depends = bar depends = foobar: x86_64 only Just an idea. Comments welcome. > > 2) Which 'pkgname' will be unique - from PKGBUILD or AURINFO? E.g if I >upload package with name 'foo' and overriden name 'bar' will someone >be able to upload new package with name 'foo'? Or 'bar'? Only the information from .AURINFO will be used. You can already trick the AUR into reading a completely different name from the PKGBUILD than it actually produces (and that problem is unavoidable), so that isn't a (new) issue. > > -- > > Regards, > Anton Larionov
Re: [aur-general] Please remove cov-analysis-bin (no download)
Am 12.01.2014 16:03, schrieb Evgeniy Alekseev: On Sunday 12 January 2014 15:55:13 Johannes Dewender wrote: Am 12.01.2014 14:11, schrieb Evgeniy Alekseev: On Sunday 12 January 2014 12:43:47 Johannes Dewender wrote: Pleare remove https://aur.archlinux.org/packages/cov-analysis-bin/ from the AUR. I created the package and was the last maintainer. However, upstream removed any possibility to download even the binary of the tool without logging in. So there is no sense to include it in the AUR anymore. Note that https://aur.archlinux.org/packages/coverity-submit/ is still available since that tool is open source. That tool only makes sense when one also installs cov-analysis from some other source (manually, without AUR), though. It may be kept in AUR. For example, some packages, such as vmd, ttf-win7- fonts, require a preload of source files. In this case to install a package you need download tarball, download source files and build and install it using makepkg (not automatical tools like packer or yaourt). Do you still want to remove this package? Yes. the package does nothing more than extracting the tarball to /opt. Okay, as you wish. The package had been removed. Thank you. For anybody thinking otherwise: The old PKGBUILD will still be available here: https://github.com/JonnyJD/PKGBUILDs/blob/c489e2cd380e2bc0b1f7a73eb08887f4c0085f86/_coverity/cov-analysis/PKGBUILD
Re: [aur-general] Please remove cov-analysis-bin (no download)
On Sunday 12 January 2014 15:55:13 Johannes Dewender wrote: > Am 12.01.2014 14:11, schrieb Evgeniy Alekseev: > > On Sunday 12 January 2014 12:43:47 Johannes Dewender wrote: > >> Pleare remove > >> https://aur.archlinux.org/packages/cov-analysis-bin/ > >> from the AUR. > >> > >> I created the package and was the last maintainer. > >> However, upstream removed any possibility to download even the binary of > >> the tool without logging in. > >> > >> So there is no sense to include it in the AUR anymore. > >> > >> Note that https://aur.archlinux.org/packages/coverity-submit/ > >> is still available since that tool is open source. > >> That tool only makes sense when one also installs cov-analysis from some > >> other source (manually, without AUR), though. > > > > It may be kept in AUR. For example, some packages, such as vmd, ttf-win7- > > fonts, require a preload of source files. In this case to install a > > package > > you need download tarball, download source files and build and install it > > using makepkg (not automatical tools like packer or yaourt). > > > > Do you still want to remove this package? > > Yes. the package does nothing more than extracting the tarball to /opt. Okay, as you wish. The package had been removed. -- С уважением, Е.Алексеев. Sincerely yours, E.Alekseev. e-mail: darkarca...@mail.ru ICQ: 407-398-235 Jabber: arca...@jabber.ru signature.asc Description: This is a digitally signed message part.
Re: [aur-general] Promoting use of .AURINFO
On Sun, 12 Jan 2014 at 15:20:03, Sébastien Luttringer wrote: > On 12/01/2014 14:35, Lukas Fleischer wrote: > > Hi, > > > > I think we should promote the use of .AURINFO files. Currently, only a > > very small fraction of packages use it. A basic description of its > > format can be found in the commit message of AUR commit 5a11373 [1]. > > Regardless of whether we keep that format or use something entirely > > different for metadata later, it is good to have this information stored > > somewhere and the format is simple enough to migrate to another format > > later. > > > Hi, > > I read the commit info but why do we need another file? What's the > purpose of overriding PKGBUILD variables in AUR? * It is impossible to extract information from a PKGBUILD properly in general (for example if there are conflicting package descriptions for different architectures, different dependencies depending on machine-specific stuff), the user is the only one to decide what to display on the AUR in these cases. * It is hard to extract information from a PKGBUILD when common bash features (variable substitutions etc.) are used -- basically requires "execution" of the PKGBUILD -- this is better done on the client side. * The current PKGBUILD parser in the AUR is extremely hackish and should be removed. > > Cheers, > > -- > Sébastien "Seblu" Luttringer > https://seblu.net > GPG: 0x2072D77A >
Re: [aur-general] Please remove cov-analysis-bin (no download)
Am 12.01.2014 14:11, schrieb Evgeniy Alekseev: On Sunday 12 January 2014 12:43:47 Johannes Dewender wrote: Pleare remove https://aur.archlinux.org/packages/cov-analysis-bin/ from the AUR. I created the package and was the last maintainer. However, upstream removed any possibility to download even the binary of the tool without logging in. So there is no sense to include it in the AUR anymore. Note that https://aur.archlinux.org/packages/coverity-submit/ is still available since that tool is open source. That tool only makes sense when one also installs cov-analysis from some other source (manually, without AUR), though. It may be kept in AUR. For example, some packages, such as vmd, ttf-win7- fonts, require a preload of source files. In this case to install a package you need download tarball, download source files and build and install it using makepkg (not automatical tools like packer or yaourt). Do you still want to remove this package? Yes. the package does nothing more than extracting the tarball to /opt. -- JonnyJD
Re: [aur-general] Promoting use of .AURINFO
On Sun, Jan 12, 2014 at 02:35:33PM +0100, Lukas Fleischer wrote: > Hi, > > I think we should promote the use of .AURINFO files. Currently, only a > very small fraction of packages use it. A basic description of its > format can be found in the commit message of AUR commit 5a11373 [1]. > Regardless of whether we keep that format or use something entirely > different for metadata later, it is good to have this information stored > somewhere and the format is simple enough to migrate to another format > later. > > I think we should at least come up with a tiny tool to generate this > kind of metadata post-makepkg and put it into the source tarball, then > add some information to the submission section in the official AUR wiki > article [2]. Does anyone have plans to write such a tool? Did anyone > already integrate this functionality into an existing AUR uploader? If > no one steps up, I might attempt to write one on my own in a couple of > days. > > I might also add a deprecation warning for source tarballs without > .AURINFO files in one of the upcoming AUR releases. > > Regards, > Lukas > > [1] > https://projects.archlinux.org/aur.git/commit/?id=5a1137363cb358593a64e0e6d0b0adeb1a9514ff > [2] > https://wiki.archlinux.org/index.php/AUR_User_Guidelines#Submitting_packages Hello, I was under the impression that .AURINFO was introduced to override some fields in PKGBUILD when they are written in format which can't be properly displayed by AUR (or maybe I've missed something). But why do you want to force it's usage for all packages? In most cases AURINFO will just duplicate same fields from PKGBUILD. Also I have some questions about it's format: 1) If package has different dependencies for 86_64 and 686, what should I put in depend array? 2) Which 'pkgname' will be unique - from PKGBUILD or AURINFO? E.g if I upload package with name 'foo' and overriden name 'bar' will someone be able to upload new package with name 'foo'? Or 'bar'? -- Regards, Anton Larionov
[aur-general] Orpan request: xgraph
Hello, I'd like to request the 'xgraph' [1] package to be orphaned. It doesn't build for a few months, and I have posted an updated PKGBUILD in the comments in Dec 7th 2013, with no answer from the maintainer. A few days later (Dec 18th) I marked the package out-of-date and emailed the maintainer Sven, but got no response so far, almost a month later. Best Regards, Sergio [1] https://aur.archlinux.org/packages/xgraph/
Re: [aur-general] Promoting use of .AURINFO
On 12/01/2014 14:35, Lukas Fleischer wrote: > Hi, > > I think we should promote the use of .AURINFO files. Currently, only a > very small fraction of packages use it. A basic description of its > format can be found in the commit message of AUR commit 5a11373 [1]. > Regardless of whether we keep that format or use something entirely > different for metadata later, it is good to have this information stored > somewhere and the format is simple enough to migrate to another format > later. > Hi, I read the commit info but why do we need another file? What's the purpose of overriding PKGBUILD variables in AUR? Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net GPG: 0x2072D77A signature.asc Description: OpenPGP digital signature
[aur-general] Promoting use of .AURINFO
Hi, I think we should promote the use of .AURINFO files. Currently, only a very small fraction of packages use it. A basic description of its format can be found in the commit message of AUR commit 5a11373 [1]. Regardless of whether we keep that format or use something entirely different for metadata later, it is good to have this information stored somewhere and the format is simple enough to migrate to another format later. I think we should at least come up with a tiny tool to generate this kind of metadata post-makepkg and put it into the source tarball, then add some information to the submission section in the official AUR wiki article [2]. Does anyone have plans to write such a tool? Did anyone already integrate this functionality into an existing AUR uploader? If no one steps up, I might attempt to write one on my own in a couple of days. I might also add a deprecation warning for source tarballs without .AURINFO files in one of the upcoming AUR releases. Regards, Lukas [1] https://projects.archlinux.org/aur.git/commit/?id=5a1137363cb358593a64e0e6d0b0adeb1a9514ff [2] https://wiki.archlinux.org/index.php/AUR_User_Guidelines#Submitting_packages
Re: [aur-general] Please remove cov-analysis-bin (no download)
On Sunday 12 January 2014 12:43:47 Johannes Dewender wrote: > Pleare remove > https://aur.archlinux.org/packages/cov-analysis-bin/ > from the AUR. > > I created the package and was the last maintainer. > However, upstream removed any possibility to download even the binary of > the tool without logging in. > > So there is no sense to include it in the AUR anymore. > > Note that https://aur.archlinux.org/packages/coverity-submit/ > is still available since that tool is open source. > That tool only makes sense when one also installs cov-analysis from some > other source (manually, without AUR), though. It may be kept in AUR. For example, some packages, such as vmd, ttf-win7- fonts, require a preload of source files. In this case to install a package you need download tarball, download source files and build and install it using makepkg (not automatical tools like packer or yaourt). Do you still want to remove this package? -- С уважением, Е.Алексеев. Sincerely yours, E.Alekseev. e-mail: darkarca...@mail.ru ICQ: 407-398-235 Jabber: arca...@jabber.ru signature.asc Description: This is a digitally signed message part.
[aur-general] Please remove cov-analysis-bin (no download)
Pleare remove https://aur.archlinux.org/packages/cov-analysis-bin/ from the AUR. I created the package and was the last maintainer. However, upstream removed any possibility to download even the binary of the tool without logging in. So there is no sense to include it in the AUR anymore. Note that https://aur.archlinux.org/packages/coverity-submit/ is still available since that tool is open source. That tool only makes sense when one also installs cov-analysis from some other source (manually, without AUR), though. -- JonnyJD
Re: [aur-general] Orphan request for 'cdp' package
On Sun, Jan 12, 2014 at 02:35:21PM +0400, Evgeniy Alekseev wrote: > On Sunday 12 January 2014 14:31:07 Evgeniy Alekseev wrote: > > He is not a maintainer, he is a contributor. Current mantainer's email could > > be found in his profile [1]. And for the future. You may leave a comment on > > package page. > > > > [1] https://aur.archlinux.org/account/Diego > > Oh, sorry. I just want to clarify. You may leave a comment on package page if > e-mail will be unavailable. Of course contact via e-mail is preferred. No problem. Actually my mistake: I should have contacted the maintainer 'Diego' and not the submitter 'delmonico'. :-) I'll try again.. Thanks Andreas > -- > ?? ??, ??.. > Sincerely yours, E.Alekseev. > > e-mail: darkarca...@mail.ru > ICQ: 407-398-235 > Jabber: arca...@jabber.ru -- Andreas Baumann Trottenstrasse 20 CH-8037 Zuerich Telefon: +41(0)76/373 01 29 E-mail: abaum...@yahoo.com Homepage: www.andreasbaumann.cc
[aur-general] Concern about 'weepcraft' package
I came across a package in the AUR recently updated called 'weepcraft.' It is apparently a hacked Minecraft client, most likely intended for malicious purposes. Additionally, Mojang states in the Minecraft product not to redistribute the software, and the "Weepcraft" website apparently does just that.
Re: [aur-general] Orphan request for 'cdp' package
On Sunday 12 January 2014 14:31:07 Evgeniy Alekseev wrote: > He is not a maintainer, he is a contributor. Current mantainer's email could > be found in his profile [1]. And for the future. You may leave a comment on > package page. > > [1] https://aur.archlinux.org/account/Diego Oh, sorry. I just want to clarify. You may leave a comment on package page if e-mail will be unavailable. Of course contact via e-mail is preferred. -- С уважением, Е.Алексеев. Sincerely yours, E.Alekseev. e-mail: darkarca...@mail.ru ICQ: 407-398-235 Jabber: arca...@jabber.ru signature.asc Description: This is a digitally signed message part.
Re: [aur-general] Orphan request for 'cdp' package
Hi! On Sunday 12 January 2014 11:14:45 Andreas Baumann wrote: > I would like to request the 'cdp' package to be orphaned: > > https://aur.archlinux.org/packages/cdp/ > > I tried to contact the maintainer at 'delmon...@gmx.net', but I get > mail delivery errors: > > 550 Requested action not taken: mailbox unavailable [RCPT_TO] He is not a maintainer, he is a contributor. Current mantainer's email could be found in his profile [1]. And for the future. You may leave a comment on package page. [1] https://aur.archlinux.org/account/Diego -- С уважением, Е.Алексеев. Sincerely yours, E.Alekseev. e-mail: darkarca...@mail.ru ICQ: 407-398-235 Jabber: arca...@jabber.ru signature.asc Description: This is a digitally signed message part.
[aur-general] Orphan request for 'cdp' package
Hi, I would like to request the 'cdp' package to be orphaned: https://aur.archlinux.org/packages/cdp/ I tried to contact the maintainer at 'delmon...@gmx.net', but I get mail delivery errors: 550 Requested action not taken: mailbox unavailable [RCPT_TO] Thanks Andreas -- Andreas Baumann Trottenstrasse 20 CH-8037 Zuerich Telefon: +41(0)76/373 01 29 E-mail: abaum...@yahoo.com Homepage: www.andreasbaumann.cc
[aur-general] Signoff report for [community-testing]
=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 6 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 1 fully signed off package * 69 packages missing signoffs * 50 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [community-testing] in last 24 hours (6 total) == * r8168-lts-8.037.00-3 (i686) * tp_smapi-lts-0.41-22 (i686) * virtualbox-modules-lts-4.3.6-3 (i686) * r8168-lts-8.037.00-3 (x86_64) * tp_smapi-lts-0.41-22 (x86_64) * virtualbox-modules-lts-4.3.6-3 (x86_64) == Incomplete signoffs for [community] (69 total) == * afpfs-ng-0.8.1-8 (i686) 0/1 signoffs * ario-1.5.1-3 (i686) 0/1 signoffs * blender-10:2.69.a0dbee6e-3 (i686) 0/1 signoffs * clamz-0.5-2 (i686) 0/1 signoffs * collectd-5.4.0-2 (i686) 0/1 signoffs * gambas3-3.5.1-3 (i686) 0/1 signoffs * gloox-1.0.9-3 (i686) 0/1 signoffs * gnunet-0.10.0-1 (i686) 0/1 signoffs * gnunet-gtk-0.10.0-1 (i686) 0/1 signoffs * gnustep-base-1.24.5-5 (i686) 0/1 signoffs * gogglesmm-0.12.7-3 (i686) 0/1 signoffs * gq-1.3.4-3 (i686) 0/1 signoffs * gwenhywfar-4.3.3-4 (i686) 0/1 signoffs * kmess-2.0.6.2-5 (i686) 0/1 signoffs * kvpnc-0.9.6a-5 (i686) 0/1 signoffs * libmicrohttpd-0.9.32-2 (i686) 0/1 signoffs * lightdm-1:1.8.5-3 (i686) 0/1 signoffs * mailutils-2.2-10 (i686) 0/1 signoffs * netcf-0.2.3-3 (i686) 0/1 signoffs * openimageio-1.3.10-1 (i686) 0/1 signoffs * openshadinglanguage-1.5.4dev-1 (i686) 0/1 signoffs * pianobar-2013.09.15-2 (i686) 0/1 signoffs * pokerth-1.1-1 (i686) 0/1 signoffs * r8168-lts-8.037.00-3 (i686) 0/1 signoffs * remmina-1.0.0-11 (i686) 0/1 signoffs * rsyslog-7.4.7-2 (i686) 0/1 signoffs * rubinius-2.2.3-2 (i686) 0/1 signoffs * tcplay-1.1-2 (i686) 0/1 signoffs * tp_smapi-lts-0.41-22 (i686) 0/1 signoffs * virtualbox-4.3.6-3 (i686) 0/1 signoffs * virtualbox-modules-lts-4.3.6-3 (i686) 0/1 signoffs * wireshark-1.10.5-3 (i686) 0/1 signoffs * xbmc-12.3-5 (i686) 0/1 signoffs * yaz-5.0.9-1 (i686) 0/1 signoffs * afpfs-ng-0.8.1-8 (x86_64) 0/2 signoffs * ario-1.5.1-3 (x86_64) 0/2 signoffs * blender-10:2.69.a0dbee6e-3 (x86_64) 0/2 signoffs * clamz-0.5-2 (x86_64) 0/2 signoffs * collectd-5.4.0-2 (x86_64) 0/2 signoffs * gambas3-3.5.1-3 (x86_64) 0/2 signoffs * gloox-1.0.9-3 (x86_64) 0/2 signoffs * gnunet-0.10.0-1 (x86_64) 0/2 signoffs * gnunet-gtk-0.10.0-1 (x86_64) 0/2 signoffs * gnustep-base-1.24.5-5 (x86_64) 0/2 signoffs * gogglesmm-0.12.7-3 (x86_64) 0/2 signoffs * gq-1.3.4-3 (x86_64) 0/2 signoffs * gwenhywfar-4.3.3-4 (x86_64) 0/2 signoffs * kmess-2.0.6.2-5 (x86_64) 0/2 signoffs * kvpnc-0.9.6a-5 (x86_64) 0/2 signoffs * libmicrohttpd-0.9.32-2 (x86_64) 0/2 signoffs * lightdm-1:1.8.5-3 (x86_64) 0/2 signoffs * mailutils-2.2-10 (x86_64) 0/2 signoffs * netcf-0.2.3-3 (x86_64) 0/2 signoffs * openimageio-1.3.10-1 (x86_64) 0/2 signoffs * openshadinglanguage-1.5.4dev-1 (x86_64) 0/2 signoffs * pianobar-2013.09.15-2 (x86_64) 0/2 signoffs * pidgin-otr-4.0.0-2 (x86_64) 1/2 signoffs * pokerth-1.1-1 (x86_64) 0/2 signoffs * r8168-lts-8.037.00-3 (x86_64) 0/2 signoffs * remmina-1.0.0-11 (x86_64) 0/2 signoffs * rsyslog-7.4.7-2 (x86_64) 0/2 signoffs * rubinius-2.2.3-2 (x86_64) 0/2 signoffs * tcplay-1.1-2 (x86_64) 0/2 signoffs * tp_smapi-lts-0.41-22 (x86_64) 0/2 signoffs * virtualbox-4.3.6-3 (x86_64) 0/2 signoffs * virtualbox-modules-lts-4.3.6-3 (x86_64) 0/2 signoffs * wireshark-1.10.5-3 (x86_64) 0/2 signoffs * xbmc-12.3-5 (x86_64) 0/2 signoffs * yaz-5.0.9-1 (x86_64) 0/2 signoffs == Completed signoffs (1 total) == * pidgin-otr-4.0.0-2 (i686) == All packages in [community-testing] for more than 14 days (50 total) == * ario-1.5.1-3 (i686), since 2013-12-25 * gloox-1.0.9-3 (i686), since 2013-12-25 * mailutils-2.2-10 (i686), since 2013-12-25 * libmicrohttpd-0.9.32-2 (i686), since 2013-12-25 * kmess-2.0.6.2-5 (i686), since 2013-12-25 * ario-1.5.1-3 (x86_64), since 2013-12-25 * gwenhywfar-4.3.3-4 (i686), since 2013-12-25 * kvpnc-0.9.6a-5 (i686), since 2013-12-25 * gloox-1.0.9-3 (x86_64), since 2013-12-25 * clamz-0.5-2 (i686), since 2013-12-25 * mailutils-2.2-10 (x86_64), since 2013-12-25 * remmina-1.0.0-11 (i686), since 2013-12-25 * libmicrohttpd-0.9.32-2 (x86_64), since 2013-12-25 * gnunet-gtk-0.10.0-1 (i686), since 2013-12-25 * kmess-2.0.6.2-5 (x86_64), since 2013-12-25 * gogglesmm-0.12.7-3 (i686), since 2013-12-25 * netcf-0.2.3-3 (i686), since 2013-12-25 * gwenhywfar-4.3.3-4 (x86_64), since 2013-12-25 * gnustep-base-1.24.5-5 (i686), since 2013-12-25 * kvpnc-0.9.6a-5 (x86_64), since 2013-12-25 * pianobar-2013.09.1
