Re: [aur-general] Handling coincidental name collisions
On Feb 09 2019 20:36:16 -0500, Eli Schwartz via aur-general wrote: > On 2/9/19 2:35 PM, Xyne wrote: > >> When the package furthermore has no other defined purpose - as Morten > >> pointed out, this is clearly something overly specialized - *and* the > >> deletion was handled according to procedure (with a deletion request, > >> see below), then I don't see the issue. > > > > The deletion request itself gives an invalid reason: it was not > > "supersed"(ed) > > by the unrelated package in community. Also, just following the procedure > > (report, delete) doesn't make any difference to the validity of the > > deletion. > > Reports are just for regular users to bring the package to the attention of > > a > > TU. > > I agree -- there is no "procedure" for deleting packages at the moment, > only a partially shared sense of politeness. > > >> On the deletion request: it can be seen at [1]. It likely should have > >> been accepted by a different TU than the requester, as well as given > >> more time than 11 minutes before acception. Now if this were some > >> systemic issue, rather than the occasional mistake any of us might make, > >> then I could see why we'd have this discussion. In my experience, it is > >> the occasional mistake. > > > > I agree that it was likely just an inattentive mistake while working through > > the requests. Nevertheless, it led to a user bringing it up on the forum so > > I > > felt it necessary to address it here. It really isn't a big deal, but it > > would > > be better to avoid repeating in the future if possible. > > It was hardly an inattentive mistake while working through requests when > the same TU who submitted the request after adding a totally different > package to community under the same name, also clicked the delete button > 11 minutes later. I am mostly a "reader" in this list, but I though I'll contribute my two cents: maybe the (currently missing) procedure for deleting packages should stipulate that the same TU cannot submit deletion request and then act on it. Can this be enforced in the software? Assuming ordinary users cannot accept delete requests, the only change then should be to check if TU that is trying to accept the delete request is not the same TU that submitted the request in the first place. Cheers, Misha -- Vanush "Misha" Paturyan Computer Science Department Maynooth University Maynooth signature.asc Description: PGP signature
Re: [aur-general] [tu-bylaws] [PATCH] Clarify the process for Special Removal of an inactive TU
On Thu, Jan 18, 2018 at 06:18:11PM -0500, Eli Schwartz via aur-general wrote: > +2. performed any action that required TU privileges on the AUR, for example > +resolving package requests, modifying user accounts, or force pushing to a > +package base, but NOT including participation in a voting period I'm not a TU, but can I suggest replacing "for example" with "such as"? "such as... but not including" sounds nicer. -- Vanush "Misha" Paturyan Senior Technical Officer Room 120 Computer Science Department Eolas Bulding Maynooth University Maynooth ext: 4539 signature.asc Description: PGP signature
Re: [aur-general] LaTeX compilation error in makepkg
> On 10 Feb 2017, at 18:45, Bennett Piater wrote: > > Well yeah, I'm building in a clean chroot using the devtools > (mkarchchroot + makechrootpkg)... :/ > > My PKGBUILD looks almost exactly like what you did, yes. > > Pasted here: > https://vps1.piater.name/commie/#xWcSmoLX > > I'm frankly stunned… > What if you stick a "set -x" just before the build() declaration in the PKGBUILD (that would generate a much bigger output, but might shed some light on what exactly is going on with your system). Misha. --- Vanush "Misha" Paturyan Senior Technical Officer Room 120 Computer Science Department EOLAS Building Maynooth University Maynooth signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [aur-general] LaTeX compilation error in makepkg
> On 9 Feb 2017, at 15:21, Bennett Piater wrote:
>
> Hi,
> I resurrected beamer-theme-metropolis when aurphan showed me that it's
> maintainer had orphaned it because I use it quite a lot.
>
> The upstream was recently updated, but I cannot get it to compile from
> makepkg -- the latex compiler complains that it cannot write to it's log
> file.
> I didn't change the PKGBUILD besides updating the version and dependencies.
>
> Output:
> https://vps1.piater.name/commie/#5O9xSO3P
>
> Everything works if I cd into $srcdir/$pkgname-$pkgver and execute make
> from the shell.
>
I've tried to build beamer-theme-metropois in a "clean" Docker
container with minimal set of packages, and I cannot reproduce your
error: beamer-theme-metropolis builds and installs perfectly (I
haven't tried using it though).
As you haven't provided PKGBUILD file I'm only guessing what changes
you have made to it to make it work. Apart from changing "pkgver" and
"sha5sums" variables I also had to modify "depends" array. I'm
attaching the diff below:
Are you building in a "clean" environment?
---
PKGBUILD | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/PKGBUILD b/PKGBUILD
index c693213..099ccfe 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -1,15 +1,15 @@
# Maintainer: Bennett Piater
pkgname=beamer-theme-metropolis
-pkgver=1.1
+pkgver=1.2
pkgrel=1
pkgdesc="A modern LaTeX Beamer theme"
url="https://github.com/matze/mtheme";
arch=("any")
license=("custom:cc-by-sa-4.0")
-depends=("texlive-core" "texlive-pictures" "otf-fira-fonts")
+depends=("texlive-core" "texlive-pictures" "texlive-latexextra"
"otf-fira-mono" "otf-fira-sans")
source=("https://github.com/matze/mtheme/archive/v${pkgver}.tar.gz";)
install=metropolis-theme.install
-sha512sums=('36eb3778e0acf75539e2d8d930ebc81202a4a6648d485963010459f25424a334c4bdf5d10f9619415908564faa282f726913ba3eba8a498f0ec9e286181540d2')
+sha512sums=('61e921a425f16b3fd12961533a5e2ec790d7d80e06d98a837156693082dd8254dfb9840498ce8e561924fb8c5241e9934e9cb1e7b7f1f8caef3cbd8edfae4af7')
build() {
# Generate the style files.
--
2.11.0
---
Vanush "Misha" Paturyan
Senior Technical Officer
Room 120
Computer Science Department
EOLAS Building
Maynooth University
Maynooth
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [aur-general] Not receiving own emails send to the list
On Wed, Jan 11, 2017 at 01:08:07AM +0100, Bruno Pagani via aur-general wrote: > Hi there, > > With my recent email address change followed by my email spree to this > list (because of my TU application mostly), I’ve noticed I’m not > receiving my own emails, despite “Receive your own posts to the list?” > being set to “Yes”. > > I suppose this is linked to SPF/DKIM/DMARC and the fact mailman > sometimes (based on original sender domains using those techs I guess) > replaces the From address while putting the original sender in the CC > field. Maybe when it does so it forgets to send also to this CC address, > and doesn’t send through the ML because of the “Avoid duplicate copies > of messages” being triggered by the CC field? > > Can anyone confirm this? I suppose any GMail user can for instance… > > Note, for this email, I’m trying “Avoid duplicate copies of messages” to > “No” in order to check whether it changes anything, which I kind of > expect given my current analysis of this issue, but that isn’t a proper > solution since it will indeed results in duplicate copies. I might be wrong here, but I think it is gmail's "feature" not to show you your own emails that are coming back via mailing lists. I was investigating similar complain by a gmail user that he does not receive his own emails via mailing list, and my conclusion was gmail silently deletes them. Hope this helps Misha. -- Vanush "Misha" Paturyan Senior Technical Officer Room 120 Computer Science Department Eolas Bulding Maynooth University Maynooth ext: 4539 signature.asc Description: PGP signature
Re: [aur-general] Split packages
On Mon, Aug 22, 2016 at 01:14:14PM +0200, Bruno Pagani wrote: > > > Le 22 août 2016 12:53:04 GMT+02:00, Lukas Mosimann a écrit : > >Hi all, > > > >Christoph Gysin came up with the problem of split packages that > >conflict > >each other, which is implementable in a PKGBUILD. > > > >As an example consider > >https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pasystray which > >defines pasystray and pasystray-gtk2 which cannot be installed both at > >the same time. Neither aura nor yaourt supports such packages. > > > >There is no other package known to me, but there should be some > >clarification, whether such a package is allowed. > > > >In my opinion, already the name "split package" indicates that these > >should not conflict, otherwise it would not just be a split package, > >but > >rather something like a "versioned package". > > > >In order to come to a conclusion for the discussion in the comments of > >that AUR package, I would kindly ask you for your thoughts concerning > >this problem. > > > >Best, > >Lukas > > AFAIR, the intent of split packages is to avoid downloading the > source/building multiple times when possible in case you want to > install part or all of the corresponding packages. > > Thus, I think there is no point in conflicting split packages, and > regarding your example, that should then be two different packages. But then you will have two PKGBUILDs that only differ by few lines within the build() function, and two separate repositories to support them. They are not two different packages, they are the same package but compiled differently. I think it makes sence to have one PKGBUILD that can procude different packages, and they have to conflict with each other to make sure someone does not install both at the same time. If tools cannot handle it then tools should be modified to allow for this workflow. just my two cents. Misha -- Vanush "Misha" Paturyan Senior Technical Officer Room 120 Computer Science Department Eolas Bulding Maynooth University Maynooth ext: 4539
