Re: [aur-general] AUR Best Practice for New Package Upload
On Fri, 9/19/14, David Phillips wrote: Subject: Re: [aur-general] AUR Best Practice for New Package Upload To: "Discussion about the Arch User Repository (AUR)" Date: Friday, September 19, 2014, 8:27 AM >makepkg doesn't delete them. It's your work. Not by default, but if you call makepkg with the -c flag, it will perform a clean-up of those temp directories. -- David Phillips GPG Key 0x7BF3D17D0884BF5B Fingerprint 2426 235A 7831 AA2F 56AF 4BC0 7BF3 D17D 0884 BF5B OK, I see that option: -c, --clean Clean up work files after build Anyway, I should have known better than to ask that questionI have built quite a few AUR packages locally and I always see the pkg and src dirs in along with the .pkg.tar.xz file, etc.; all the time. when I go to pacman -U to install. So the answer to that question was pretty obvious; just got confused there for a minute. I do need to read up more on how $SRCDEST , $PKGDIR and $SRCDIR are defined and work together, etc. (Just a matter of finding the right man page sections) Thanks.
Re: [aur-general] AUR Best Practice for New Package Upload
>makepkg doesn't delete them. It's your work. Not by default, but if you call makepkg with the -c flag, it will perform a clean-up of those temp directories. -- David Phillips GPG Key 0x7BF3D17D0884BF5B Fingerprint 2426 235A 7831 AA2F 56AF 4BC0 7BF3 D17D 0884 BF5B
Re: [aur-general] Java name guideliness
but upstream name not necesary mean the name that the encapsulate that contain the package need to be named. There ar a handfull either throw arch and aur history and actual named packages that not follow the name. but too looking to the other packages in aur the version is alwas separate from the name of the package so in the end - will be used. Upstream not give a version or give a "-" or a plain space for versions if ou are going to follow uptream. 2014-09-18 16:54 GMT-03:00 Det : > On Thu Sep 11 14:02:41 EDT 2014, Pablo Lezaeta Reyes wrote: > > If look to the pther packages (not java) the fewers who need a version > they > > apend the versión at the endm so for consistency whit the all others > > packages I think is better keep the version at the end: > > --: oracle/openjdk-jre-7/8 > > We can't do that, because our own upstream (the OpenJDK packager) alredy > decided on it. To change it you're going to have to start a bug > report/feature request on our own packages. > > If you can change _his_ mind, then we can talk about implementing that in > the AUR as well. > > On Thu Sep 11 18:13:11 EDT 2014, Justin Dray wrote: > > The fact that one naming convention or the other being chosen is still > not > > the issue, it's the fact that in the interim there are *both* packages in > > there. > > Yes, I get that you're eager to get whatever parties out of there ASAP, and > sort it out later. Unfortunately, that's not how it's going to play out and > this discussion so far has prevented the proper way from happening as well, > as I was already pointed out some time ago. > > Therefore, I'm taking this and my suggestions back directly to the > respective maintainers, and only if they want to continue it here, we will. > > Det > -- *Pablo Lezaeta*
Re: [aur-general] AUR Best Practice for New Package Upload
On Thu, 9/18/14, Nuno Araujo wrote: Subject: Re: [aur-general] AUR Best Practice for New Package Upload To: aur-general@archlinux.org Date: Thursday, September 18, 2014, 10:00 PM As a generic advice, take the time to read the man pages of Arch Linux build system utilities and configuration files (e.g. man PKGBUILD, man makepkg, man pacman, man pacman.conf, and so on...). Also read other AUR PKGBUILDs (or even better, the one published in core and extra repositories). There you would have find answers for some of the questions you asked. -- Nuno Araujo http://www.russo79.com OK, got all of that, thanks again for feedback and guidance. Oh, and I did read the man pages of makepkg and pacman maybe not all of the data but whatever I could find that applied to my questions but it's always good to double check my understanding (or misunderstanding, as the case may be), since I'm still learning. I always do that before posting but again, not so obvious at times. I think I'm pretty much ready to go here and will proceed to upload soon. Thanks.
Re: [aur-general] AUR Best Practice for New Package Upload
On jeu, 2014-09-18 at 11:26 -0700, stef wrote: > > On Tue, 9/16/14, Nuno Araujo wrote: > > Subject: Re: [aur-general] AUR Best Practice for New Package Upload > To: aur-general@archlinux.org > Date: Tuesday, September 16, 2014, 1:42 PM > > > Try to study it and feel > free to ask any questions you want about it. > > > -- > Nuno Araujo > http://www.russo79.com > > > = > @nuno > @list > > So, I have studied the PKGBUILD and install file. > > I have some questions, a few of which might be really newb-type but please > bear with me. > > All is clear in your PKGBUILD: and it was certainly helpful to see how you > went about it; clean and simple. > > 1) Questions regarding the variables $pkgdir and $srcdir . > > My understanding: these 2 babies are directories created by makepkg during > the fetch source, configure, build and install to fakeroot process. > $srcdir is where makepkg stores all source files downloaded. > $pkgdir is where the build/compiled files are then stored in the fakeroot > environment which gets compressed into the final .pkg.tar.xz file. THAT > .tar.xz file is a compressed archive which contains the directory structure > and installed files which pacman will then extract to user's root system. > > a) Did i get this right? More or less, the source files are into $SRCDEST, which defaults to the current directory. (you should take a look at makepkg.conf man page). $srcdir is a folder where the source files are uncompressed (or symlinked). As for $pkgdir, you are right. It should be noted that besides the built/compiled files, the .install files as well as a .PKGINFO file providing the package metadata is also in that directory. > b) what happens to $srcdir and $pkgdir ? I imagine those are just 'temp' dirs > which makepkg deletes when it's done compressing the fakeroot? makepkg doesn't delete them. It's your work. > > 2) in the PKGBUILD, you are dropping the data/ directory and installing both > .svg and .glade files to /usr/share/masshash-launcher/ > > In python3/ masshash-launcher: > > L31 #path to glade ui file > L32 glade_source_dir = '../data/masshash-launcher.glade' > L33 if os.path.isfile(glade_source_dir): > L34 glade = glade_source_dir > L35 else: > L36 glade = '/usr/share/masshash-launcher/masshash-launcher.glade' > > So you're using L36 as opposed to 32. > > This is your preference? Or for the sake of simplicity? So as not to create > an additional dir "data" as unnecessary? > > (Sorry not trying to be "anal" but only to understand.) Neither. If you give it a look, you'll see that L32 refers to a relative path. This is usually used when developing a program. While coding, you would like to access your work version of the files. This allows work to be done on a "development" version of the program without affecting the one installed on your system. > > 3) You are copying the svg file to /usr/share/icons/hicolor/scalable/apps/ > Then you are using the install file to update the gtk icon cache--which I > didn't even think of and makes a lot of sense. > Why the hicolor though? Your choice? Because it is the most basic/core GTK > icon theme? > > Sorry, but this is all a bit new to me. If you give a look at the contents of the hicolor-icon-theme package, you will see that it has no icons by itself. Only a "standard" set of directories where icons should to be stored and a index file describing these directories. Having this theme installed ensure that you can call gtk-update-icon-cache without issues. This "theme" is usually the standard place to store your application icons (at least in a XDG "compatible" desktop). > > 4) Not important; for the CLI program, the category I would use to upload to > AUR would be "system" but since we also have the GUI, (which would be what > X11?), which category would you recommend when uploading to AUR? X11? My personal opinion: I don't care about AUR categories. But if I had to choose between both, I would pick "system". > > 5) @nuno : Do you want to be listed as contributor? Would only be (more > than) fair (eeer...) but might be a bit of a PITA for youJust let me know. Don't care. Seing the time and effort you're putting to study a single and simple PKGBUILD, you deserve to take all the credit for it. > > Thanks. As a generic advice, take the time to read the man pages of Arch Linux build system utilities and configuration files (e.g. man PKGBUILD, man makepkg, man pacman, man pacman.conf, and so on...). Also read other AUR PKGBUILDs (or even better, the one published in core and extra repositories). There you would have find answers for some of the questions you asked. -- Nuno Araujo http://www.russo79.com signature.asc Description: This is a digitally signed message part
Re: [aur-general] Java name guideliness
On Thu Sep 11 14:02:41 EDT 2014, Pablo Lezaeta Reyes wrote: > If look to the pther packages (not java) the fewers who need a version they > apend the versión at the endm so for consistency whit the all others > packages I think is better keep the version at the end: > --: oracle/openjdk-jre-7/8 We can't do that, because our own upstream (the OpenJDK packager) alredy decided on it. To change it you're going to have to start a bug report/feature request on our own packages. If you can change _his_ mind, then we can talk about implementing that in the AUR as well. On Thu Sep 11 18:13:11 EDT 2014, Justin Dray wrote: > The fact that one naming convention or the other being chosen is still not > the issue, it's the fact that in the interim there are *both* packages in > there. Yes, I get that you're eager to get whatever parties out of there ASAP, and sort it out later. Unfortunately, that's not how it's going to play out and this discussion so far has prevented the proper way from happening as well, as I was already pointed out some time ago. Therefore, I'm taking this and my suggestions back directly to the respective maintainers, and only if they want to continue it here, we will. Det
Re: [aur-general] AUR Best Practice for New Package Upload
On Tue, 9/16/14, Nuno Araujo wrote: Subject: Re: [aur-general] AUR Best Practice for New Package Upload To: aur-general@archlinux.org Date: Tuesday, September 16, 2014, 1:42 PM Try to study it and feel free to ask any questions you want about it. -- Nuno Araujo http://www.russo79.com = @nuno @list So, I have studied the PKGBUILD and install file. I have some questions, a few of which might be really newb-type but please bear with me. All is clear in your PKGBUILD: and it was certainly helpful to see how you went about it; clean and simple. 1) Questions regarding the variables $pkgdir and $srcdir . My understanding: these 2 babies are directories created by makepkg during the fetch source, configure, build and install to fakeroot process. $srcdir is where makepkg stores all source files downloaded. $pkgdir is where the build/compiled files are then stored in the fakeroot environment which gets compressed into the final .pkg.tar.xz file. THAT .tar.xz file is a compressed archive which contains the directory structure and installed files which pacman will then extract to user's root system. a) Did i get this right? b) what happens to $srcdir and $pkgdir ? I imagine those are just 'temp' dirs which makepkg deletes when it's done compressing the fakeroot? 2) in the PKGBUILD, you are dropping the data/ directory and installing both .svg and .glade files to /usr/share/masshash-launcher/ In python3/ masshash-launcher: L31 #path to glade ui file L32 glade_source_dir = '../data/masshash-launcher.glade' L33 if os.path.isfile(glade_source_dir): L34 glade = glade_source_dir L35 else: L36 glade = '/usr/share/masshash-launcher/masshash-launcher.glade' So you're using L36 as opposed to 32. This is your preference? Or for the sake of simplicity? So as not to create an additional dir "data" as unnecessary? (Sorry not trying to be "anal" but only to understand.) 3) You are copying the svg file to /usr/share/icons/hicolor/scalable/apps/ Then you are using the install file to update the gtk icon cache--which I didn't even think of and makes a lot of sense. Why the hicolor though? Your choice? Because it is the most basic/core GTK icon theme? Sorry, but this is all a bit new to me. 4) Not important; for the CLI program, the category I would use to upload to AUR would be "system" but since we also have the GUI, (which would be what X11?), which category would you recommend when uploading to AUR? X11? 5) @nuno : Do you want to be listed as contributor? Would only be (more than) fair (eeer...) but might be a bit of a PITA for youJust let me know. Thanks.
[aur-general] Signoff report for [community-testing]
=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 14 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 1 fully signed off package * 22 packages missing signoffs * 5 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 (14 total) == * acpi_call-1.1.0-12 (i686) * bbswitch-0.8-16 (i686) * r8168-8.038.00-11 (i686) * rt3562sta-2.4.1.1_r1-10 (i686) * tp_smapi-0.41-53 (i686) * vhba-module-20140629-7 (i686) * virtualbox-modules-4.3.16-2 (i686) * acpi_call-1.1.0-12 (x86_64) * bbswitch-0.8-16 (x86_64) * r8168-8.038.00-11 (x86_64) * rt3562sta-2.4.1.1_r1-10 (x86_64) * tp_smapi-0.41-53 (x86_64) * vhba-module-20140629-7 (x86_64) * virtualbox-modules-4.3.16-2 (x86_64) == Incomplete signoffs for [community] (21 total) == * freevo-1.9.0-14 (any) 0/2 signoffs * ibus-table-1.9.0-1 (any) 0/2 signoffs * salt-2014.1.11-1 (any) 0/2 signoffs * acpi_call-1.1.0-12 (i686) 0/1 signoffs * bbswitch-0.8-16 (i686) 0/1 signoffs * r8168-8.038.00-11 (i686) 0/1 signoffs * rt3562sta-2.4.1.1_r1-10 (i686) 0/1 signoffs * seamonkey-2.26.1-2 (i686) 0/1 signoffs * tp_smapi-0.41-53 (i686) 0/1 signoffs * vhba-module-20140629-7 (i686) 0/1 signoffs * virtualbox-modules-4.3.16-2 (i686) 0/1 signoffs * xulrunner-31.0-2 (i686) 0/1 signoffs * acpi_call-1.1.0-12 (x86_64) 0/2 signoffs * bbswitch-0.8-16 (x86_64) 0/2 signoffs * r8168-8.038.00-11 (x86_64) 0/2 signoffs * rt3562sta-2.4.1.1_r1-10 (x86_64) 0/2 signoffs * seamonkey-2.26.1-2 (x86_64) 0/2 signoffs * tp_smapi-0.41-53 (x86_64) 0/2 signoffs * vhba-module-20140629-7 (x86_64) 0/2 signoffs * virtualbox-modules-4.3.16-2 (x86_64) 0/2 signoffs * xulrunner-31.0-2 (x86_64) 0/2 signoffs == Incomplete signoffs for [unknown] (1 total) == * kompozer-0.8b3-15 (x86_64) 0/2 signoffs == Completed signoffs (1 total) == * kompozer-0.8b3-15 (i686) == All packages in [community-testing] for more than 14 days (5 total) == * freevo-1.9.0-14 (any), since 2014-08-27 * xulrunner-31.0-2 (i686), since 2014-08-28 * xulrunner-31.0-2 (x86_64), since 2014-08-28 * seamonkey-2.26.1-2 (x86_64), since 2014-08-28 * seamonkey-2.26.1-2 (i686), since 2014-08-28 == Top five in signoffs in last 24 hours == 1. foutrelis - 6 signoffs 2. anatolik - 6 signoffs 3. dan - 3 signoffs 4. dreisner - 2 signoffs
Re: [aur-general] Package deletion
On Wed, Sep 17, 2014 at 1:23 PM, Maxime Gauduin wrote:
>
> And I just realized you might want to use it outside of RockboxUtility and
> create your own voice files by external means. In any case, your deps and
> makedeps are wrong, the provides line is useless, you're installing ghost
> files (the rbspeex{enc,dec} are placed one directory above) and you need to
> create bin beforehand or add -D to install. Anyway, I submitted a split
> PKGBUILD which builds rbutil-git and rbspeex-git to AUR.
>
> Cheers,
> --
> Maxime
As Maxime had announced after your other emails. Content repeated
above for your convenience.
cheers!
mar77i
