Aur-general May 2014

aur-general@lists.archlinux.org

130 participants
177 discussions

[aur-general] ttf-google-webfonts{,-distilled,-git,-hg} mess
by Jason St. John 19 Jun '19

19 Jun '19

I am the current maintainer of the AUR package ttf-google-webfonts-hg[4], and I'm bothered by the mess of various packages there are for Google's Web Fonts project. It's not at all KISS in its current state. There are currently four different AUR packages[1][2][3][4] that essentially supply the same files, and all four packages conflict with each other. Around August of 2012, the package named ttf-google-webfonts[1] was orphaned, and user w0ng created a GitHub repository[5] that mirrors the Mercurial repository[6] on Google Code (why?). Then, the new maintainer changed the original ttf-google-webfonts package from a VCS-type package that simply lacked "-hg" in the name to a package that pulls tarballs from w0ng's GitHub repo[5]. As you can see in the comments for ttf-google-webfonts[1], this has caused all sorts of confusion and messages about the package being out-of-date or having invalid checksums. To get around these issues, user epinephrine created the package ttf-google-webfonts-git[3] that clones w0ng's GitHub repo[5] instead of pulling tarballs from it, which significantly reduces the maintenance required on the package. Then, user Gently created a package named ttf-google-webfonts-distilled[2] that pulls a tarball from w0ng's GitHub repo[5] and only installs a small subset of the fonts therein. Shortly after ttf-google-webfonts[1] was changed from being a Mercurial-based package and not liking the direction that the package was taking, I reuploaded the original ttf-google-webfonts package as ttf-google-webfonts-hg[4] for people that simply wanted the old package back that uses the actual Google Web Fonts repository to download the files. To clean up this mess, I propose that ttf-google-webfonts-distilled[2] and ttf-google-webfonts-git[3] be deleted outright, for what should be obvious reasons. I also propose that ttf-google-webfonts[1] be deleted because of how frequently the Web Fonts project is updated and because the project lacks version numbers. If people really feel strongly about keeping that maintenance nightmare, then let them have it, but I really don't see what advantage it provides over the original ttf-google-webfonts-hg[4] other than one less makedepends. I apologize for the huge email, but this situation really is a mess. [1] https://aur.archlinux.org/packages/ttf-google-webfonts/ [2] https://aur.archlinux.org/packages/ttf-google-webfonts-distilled/ [3] https://aur.archlinux.org/packages/ttf-google-webfonts-git/ [4] https://aur.archlinux.org/packages/ttf-google-webfonts-hg/ [5] https://github.com/w0ng/googlefontdirectory [6] https://code.google.com/p/googlefontdirectory/ Jason

14 23

[aur-general] A bit strange - unusual packages
by Rob Til Freedmen 28 Sep '14

28 Sep '14

2 3

[aur-general] [HEADS-UP] Meta data and split package support in the AUR
by Lukas Fleischer 27 Jul '14

27 Jul '14

Hello, I plan to do the next major AUR release by late May or June and I thought this might be a good time to let people know what is going on behind the scenes. AUR 3.0.0 will be able to read metadata from source packages. These metadata will be read from a file called .AURINFO (contained in the source tarball). Dave wrote several tools [1], including mkaurball which can be used to automatically build a source tarball with metadata so you don't need to worry about creating this file on your own. Having this information available means that: 1. We can drop the PKGBUILD parser from the AUR. The parser will still be available in the upcoming release but it will be marked as deprecated and a warning will be displayed whenever someone tries to upload a source tarball without metadata. 2. We can implement other things that were blocked by the AUR PKGBUILD parser being incomplete and inaccurate. Specifically, the next release will support split packages. Things that are on our TODO list: * Test the new AUR code. The split package code is still experimental. * Fix and extend the AUR RPC interface. * Test Dave's pkgbuild-introspection. * Move pkgbuild-introspection (or at least mkaurball) to [community]. It would also be nice to get metadata generation integrated into makepkg so that people no longer need to install mkaurball to generate source tarballs for the AUR. Regards, Lukas [1] https://github.com/falconindy/pkgbuild-introspection

4 6

[aur-general] Orphan Request
by mytbk920423＠gmail.com 13 Jul '14

13 Jul '14

python-colorama[1] and python2-colorama[2] has been flagged out of date for a very long time, and I'd like to adopt them. [1] https://aur.archlinux.org/packages/python-colorama/ [2] https://aur.archlinux.org/packages/python2-colorama/

4 3

[aur-general] Orphan request: l3afpad
by Steven Honeyman 05 Jun '14

05 Jun '14

The AUR package "l3afpad" is in need of an update as the source file has changed URL and it will soon stop working when the author takes his old page down. I'm willing to take over as maintainer for this package if possible. I already emailed the current maintainer, but he hasn't replied. https://aur.archlinux.org/packages/l3afpad Thanks, Steven

3 4

[aur-general] AUR 3.0.0 released
by Lukas Fleischer 05 Jun '14

05 Jun '14

Hello, I am pleased to announce that AUR 3.0.0 has just been released. The official AUR setup [1] has already been updated. Note that in order to build source packages for the AUR, you will now need to use a tool called mkaurball (instead of `makepkg --source`). It is included in the pkgbuild-introspection package [2]. For a comprehensive list of changes, please consult the Git log [3]. As usual, bugs should be reported to the AUR bug tracker [4]. [1] https://aur.archlinux.org/ [2] https://www.archlinux.org/packages/community/any/pkgbuild-introspection/ [3] https://projects.archlinux.org/aur.git/log/?id=v3.0.0 [4] https://bugs.archlinux.org/index.php?project=2

14 35

[aur-general] Duplicated package removal request
by Steven Honeyman 02 Jun '14

02 Jun '14

I've just noticed that the md5deep [1] package (kept up-to-date, first submitted in 2006) someone has duplicated to "hashdeep" [2] in 2014. They compile from exactly the same source, and produce the same binaries. Can the hashdeep package be removed? Also, would anybody be interested in moving md5deep over to the community repo? It's a very popular set of checksum tools that have many more features than md5sum,sha1sum (etc). Thanks, Steven. [1] https://aur.archlinux.org/packages/md5deep/ [2] https://aur.archlinux.org/packages/hashdeep/

7 10

[aur-general] pkg deletion request
by artux 01 Jun '14

01 Jun '14

Hi TUs, I made the switch to mkaurball, and I would like to have this package deleted for new renamed upload(pkgbase will become openrc-sys). https://aur.archlinux.org/pkgbase/openrc-base/ I also have aquestion. Suppose I want to move/merge a single pkgbuild to a split build, is that possible? Will the pkgbase change, so the single pkgbuld will "disappear" automatically? Or the other way round, I want to move a pkg from split build to single build? Is there any documentation for this kind of stuff? Thanks, artoo

3 3

[aur-general] Delete requests for obsolete XWayland packages
by Tim Jester-Pfadt 31 May '14

31 May '14

Hello, now that XWayland changed to being it's own server binary, rather than a module for X11, there are several obsolete drivers on the AUR which only create confusion.[1][2][3] The new XWayland doesn't need patched drivers anymore. "In the old model, things like modesetting were done in the video driver, unfortunately. In the old model, we simply patched Xorg with a special magical mode to tell video drivers not to do anything too tricky. For instance, the xf86-video-intel driver had a special branch for Xwayland support<http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/?h=xwayland>. For generic hardware support, we wrote a generic, unaccelerated driver<http://cgit.freedesktop.org/xorg/driver/xf86-video-wayland> that stubbed out most of the functions we needed. With the new approach, we don’t need to patch anything at all." [4] There is also an orphaned build of the development X server, which tries to build the old deprecated XWayland approach. [5] You can see this, because it has --enable-wayland instead of the new --enable-xwayland. Another build is a duplicated of the defacto standard xwayland package (xwayland-git) the difference is that it not only builds XWayland, but also the whole X11 server from the development branch even though this is not needed.[6] People could just use the xorg-server-dev and install xwayland-git and get the same thing. [1] https://aur.archlinux.org/packages/xf86-video-ati-xwayland-git/ - Orphaned [2] https://aur.archlinux.org/packages/xf86-video-intel-xwayland-git/ - Maintained by plfiorini<https://aur.archlinux.org/packages/?K=plfiorini&SeB=m> [3] https://aur.archlinux.org/packages/xf86-video-wlglamor-git/ - Orphaned [4] http://blog.mecheye.net/2014/04/xwayland/ [5] https://aur.archlinux.org/packages/xorg-server-xwayland/ - Orphaned [6] https://aur.archlinux.org/packages/xorg-server-xwayland-dev / - Maintained by maxi_jac<https://aur.archlinux.org/packages/?K=maxi_jac&SeB=m>

2 3

[aur-general] Orphan request: jdownloader2
by Marcel Dopita 31 May '14

31 May '14

The package jdownloader2 is outdated for more than 4 months now. Owner does not list his email so I wasn't able to contact him directly. Exactly two weeks ago I left a comment on AUR and also sent private message to user with same name on official jdownloader board. Both with no response. I'm requesting an orphan so I can fix it (basically a new url) and maintain. Regards, Marcel

2 1

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Aur-general May 2014