Search results for "Deletion request for pkgbase" - Aur-requests

Re: [PRQ#42226] Deletion Request for wire-desktop-appimage

by Marcell Meszaros

• AUR submission guidelines say that uploaded packages should be useful to users and significantly different than Arch repo packages. • Arch Electron packaging guidelines suggest to strip out the bundled Electron/Chromium runtime from application package. AUR/wire-desktop-appimage does not fulfill any of the above requirements. And on top, it is more bloated and potentially less secure. Therefore only Arch [extra] wire-desktop should be kept. On 18 June 2023 00:24:49 GMT+02:00, Ashleigh Rowe <administrator(a)hax.ie> wrote: >Marcell, As you so clearly pointed out, the TUs are trusted to enforce some quality quidelines on the AUR. You are not a TU. > >You claim I have not refuted your claims, however there is little reason to do so, as I have not seen you refute any of mine. I suggest we both drop this as I suggested a few messages ago, as clogging up the mailing list with this BS is hardly productive, and I didn't think I'd need to spell it out. > > >On 17/06/2023 19:07, Marcell Meszaros wrote: >> > We've already acknowledged that they are not the same. >> >> No, we can only acknowledge that we disagree on that point. >> >> I believe that Trusted Users are trusted to enforce some quality guidelines on AUR. >> >> Otherwise AUR will just descent into more and more chaos. >> >> Which does not benefit either users, nor maintainers or TU's themselves. >> >> When an Electron (Javascript) application is already properly configured and hosted in Arch repo, it is detrimental to have on AUR a differently packaged copy of the same internal contents with unnecessary and potentially insecure duplicated chromium/electron runtime. >> >> You have not refuted the validity of any of my points above. >> >> >> On 17 June 2023 19:41:05 GMT+02:00, Ashleigh Rowe <administrator(a)hax.ie> wrote: >> >> In your opinion, maybe. but to anyone who actually prefers >> appimages? Not so much. >> Just drop it. We've already acknowledged that they are not the same. >> >> On 17/06/2023 17:37, Marcell Meszaros wrote: >>> I am not at all against AppImage. >>> >>> But the latest wire-desktop is in Arch repo, so having >>> wire-desktop-appimage in AUR is pointless. >>> >>> >>> On 17 June 2023 18:23:08 GMT+02:00, Ashleigh Rowe >>> <administrator(a)hax.ie> wrote: >>> >>> One can also install many things on the AUR by using flatpak >>> or a package manager. Does not mean they should be removed. >>> >>> Just stop with the seeming anti-appimage, ok? >>> >>> On Sat, 17 Jun 2023, 13:51 Marcell Meszaros, >>> <marcell.meszaros(a)runbox.eu> wrote: >>> >>> One can also install a standalone AppImage file by >>> running it. It does not need to be packaged via an AUR >>> PKGBUILD. >>> >>> >>> On 16 June 2023 18:55:00 GMT+02:00, Ashleigh Rowe >>> <administrator(a)hax.ie> wrote: >>> >>> Hi Marcell, >>> >>> That may be the case, but there are many reasons to >>> want to use an appimage over a natively installed >>> application. And, given that it is not the same >>> package, it need not be deleted. Taking the same >>> logic to it's extreme, one could argue that a -git >>> and a -bin version of a package need not both be on >>> the AUR, as for users, it is the same. >>> We both know, however, that this is not the case. >>> >>> On 16/06/2023 17:31, Marcell Meszaros wrote: >>>> > So, by your own admission, it is not a duplicate >>>> of a repo package then? >>>> >>>> Hi Asleigh, >>>> >>>> Thank you for your reply. >>>> >>>> The way I see it, the Arch repo version integrates >>>> better with the system and does not include >>>> unnecessary bloat. >>>> >>>> The AUR AppImage version carries its own Electron >>>> runtime rather than using one available from Arch repo. >>>> >>>> The feature set is the same. >>>> >>>> So, for all intents and purposes, the AUR package is >>>> the same for users. >>>> >>>> Except the latter takes up more space, and is >>>> potentially more insecure >>>> >>>> There are frequent updates of Electron in repo. >>>> The AUR package won't update its built-in electron >>>> separately. >>>> >>>> On the other hand, repo's wire-desktop package will >>>> always use the latest repo-updated version of its >>>> electron runtime. >>>> >>>> All in all, the AUR version is an inferior duplicate. >>>> >>>> In my understanding, it is only useful to have >>>> AppImage packages of especially Electron-based >>>> applications on AUR if the Arch repo does not carry >>>> that application. >>>> >>>> Cheers, >>>> Marcell (Mars) >>>> >>>> >>>> On 16 June 2023 17:23:12 GMT+02:00, Ashleigh Rowe >>>> <administrator(a)hax.ie> <mailto:administrator@hax.ie> >>>> wrote: >>>> >>>> So, by your own admission, it is not a duplicate >>>> of a repo package then? >>>> >>>> On Fri, 16 Jun 2023 at 16:20, >>>> <notify(a)aur.archlinux.org> wrote: >>>> >>>> MarsSeed [1] filed a deletion request for >>>> wire-desktop-appimage [2]: >>>> >>>> Duplicate of repo package, not needed: >>>> >>>> https://archlinux.org/packages/extra/any/wire-desktop/ >>>> >>>> This is an Electron-based application, so >>>> there is no benefit in using >>>> this AppImage in a PKGBUILD. The repo >>>> version has the exact same >>>> application code. >>>> >>>> And repo verison is even better because it >>>> does not duplicate the >>>> electron runtime, but depends on the >>>> relevant repo electron package. >>>> >>>> [1] https://aur.archlinux.org/account/MarsSeed/ >>>> [2] >>>> https://aur.archlinux.org/pkgbase/wire-desktop-appimage/ >>>>

2 years, 2 months

[PRQ#52396] Deletion Request for mpd-git

by notify＠aur.archlinux.org

mackel [1] filed a deletion request for mpd-git [2]: I installed it with throw problem. Maybe it is because ffmpeg update the vmaf. FAILED: mpd c++ -o mpd mpd.p/meson-generated_.._GitVersion.cxx.o mpd.p/src_Main.cxx.o mpd.p/src_protocol_ArgParser.cxx.o mpd.p/src_command_CommandError.cxx.o mpd.p/src_command_PositionArg.cxx.o mpd.p/src_command_AllCommands.cxx.o mpd.p/src_command_QueueCommands.cxx.o mpd.p/src_command_TagCommands.cxx.o mpd.p/src_command_PlayerCommands.cxx.o mpd.p/src_command_PlaylistCommands.cxx.o mpd.p/src_command_FileCommands.cxx.o mpd.p/src_command_OutputCommands.cxx.o mpd.p/src_command_MessageCommands.cxx.o mpd.p/src_command_ClientCommands.cxx.o mpd.p/src_command_PartitionCommands.cxx.o mpd.p/src_command_OtherCommands.cxx.o mpd.p/src_command_CommandListBuilder.cxx.o mpd.p/src_config_PartitionConfig.cxx.o mpd.p/src_config_PlayerConfig.cxx.o mpd.p/src_config_ReplayGainConfig.cxx.o mpd.p/src_Idle.cxx.o mpd.p/src_IdleFlags.cxx.o mpd.p/src_decoder_Thread.cxx.o mpd.p/src_decoder_Control.cxx.o mpd.p/src_decoder_Bridge.cxx.o mpd.p/src_decoder_DecoderPrint.cxx.o mpd.p/src_client_Listener.cxx.o mpd.p/src_client_Client.cxx.o mpd.p/src_client_Config.cxx.o mpd.p/src_client_Domain.cxx.o mpd.p/src_client_Event.cxx.o mpd.p/src_client_Expire.cxx.o mpd.p/src_client_Idle.cxx.o mpd.p/src_client_List.cxx.o mpd.p/src_client_New.cxx.o mpd.p/src_client_Process.cxx.o mpd.p/src_client_Read.cxx.o mpd.p/src_client_Write.cxx.o mpd.p/src_client_Message.cxx.o mpd.p/src_client_Subscribe.cxx.o mpd.p/src_client_File.cxx.o mpd.p/src_client_Response.cxx.o mpd.p/src_client_ThreadBackgroundCommand.cxx.o mpd.p/src_Listen.cxx.o mpd.p/src_LogInit.cxx.o mpd.p/src_ls.cxx.o mpd.p/src_Instance.cxx.o mpd.p/src_MusicBuffer.cxx.o mpd.p/src_MusicPipe.cxx.o mpd.p/src_MusicChunk.cxx.o mpd.p/src_MusicChunkPtr.cxx.o mpd.p/src_Mapper.cxx.o mpd.p/src_Partition.cxx.o mpd.p/src_Permission.cxx.o mpd.p/src_player_CrossFade.cxx.o mpd.p/src_player_Thread.cxx.o mpd.p/src_player_Control.cxx.o mpd.p/src_PlaylistError.cxx.o mpd.p/src_PlaylistPrint.cxx.o mpd.p/src_PlaylistSave.cxx.o mpd.p/src_playlist_PlaylistStream.cxx.o mpd.p/src_playlist_PlaylistMapper.cxx.o mpd.p/src_playlist_PlaylistAny.cxx.o mpd.p/src_playlist_PlaylistSong.cxx.o mpd.p/src_playlist_PlaylistQueue.cxx.o mpd.p/src_playlist_Print.cxx.o mpd.p/src_db_PlaylistVector.cxx.o mpd.p/src_queue_Queue.cxx.o mpd.p/src_queue_Print.cxx.o mpd.p/src_queue_Save.cxx.o mpd.p/src_queue_Selection.cxx.o mpd.p/src_queue_Playlist.cxx.o mpd.p/src_queue_PlaylistControl.cxx.o mpd.p/src_queue_PlaylistEdit.cxx.o mpd.p/src_queue_PlaylistTag.cxx.o mpd.p/src_queue_PlaylistState.cxx.o mpd.p/src_LocateUri.cxx.o mpd.p/src_SongUpdate.cxx.o mpd.p/src_SongLoader.cxx.o mpd.p/src_SongPrint.cxx.o mpd.p/src_SongSave.cxx.o mpd.p/src_StateFile.cxx.o mpd.p/src_StateFileConfig.cxx.o mpd.p/src_Stats.cxx.o mpd.p/src_TagPrint.cxx.o mpd.p/src_TagSave.cxx.o mpd.p/src_TagFile.cxx.o mpd.p/src_TagStream.cxx.o mpd.p/src_TagAny.cxx.o mpd.p/src_TimePrint.cxx.o mpd.p/src_mixer_Memento.cxx.o mpd.p/src_PlaylistFile.cxx.o mpd.p/src_CommandLine.cxx.o mpd.p/src_unix_SignalHandlers.cxx.o mpd.p/src_unix_Daemon.cxx.o mpd.p/src_storage_StorageState.cxx.o mpd.p/src_queue_PlaylistUpdate.cxx.o mpd.p/src_command_StorageCommands.cxx.o mpd.p/src_command_DatabaseCommands.cxx.o mpd.p/src_RemoteTagCache.cxx.o mpd.p/src_command_StickerCommands.cxx.o mpd.p/src_sticker_Database.cxx.o mpd.p/src_sticker_Print.cxx.o mpd.p/src_sticker_SongSticker.cxx.o mpd.p/src_sticker_TagSticker.cxx.o mpd.p/src_sticker_AllowedTags.cxx.o mpd.p/src_sticker_CleanupService.cxx.o mpd.p/src_command_FingerprintCommands.cxx.o mpd.p/src_lib_chromaprint_DecoderClient.cxx.o mpd.p/src_command_NeighborCommands.cxx.o mpd.p/src_TagArchive.cxx.o mpd.p/src_db_update_Archive.cxx.o -flto -Wl,--as-needed -Wl,--no- undefined -pie -Wl,-z,relro -Wl,-z,now -Wl,--gc-sections -Wl,-O1,-- sort-common,--as-needed,-z,relro,-z,now -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -Wl,--start-group src/cmdline/libcmdline.a src/lib/fmt/libfmt.a libbasic.a src/config/libfs.a liblog.a src/fs/libfs.a src/lib/icu/libicu.a src/util/libutil.a src/fs/glue/libfs_glue.a src/io/libio.a src/io/libio_fs.a src/lib/dbus/libdbus.a src/event/libevent.a src/io/uring/liburing.a src/thread/libthread.a src/net/libnet.a src/system/libsystem.a src/neighbor/libneighbor_glue.a src/neighbor/plugins/libneighbor_plugins.a src/lib/upnp/libupnp.a src/lib/curl/libcurl.a src/lib/expat/libexpat.a src/input/libinput_glue.a src/input/plugins/libinput_plugins.a src/lib/alsa/libalsa.a src/pcm/libpcm_basic.a src/lib/ffmpeg/libffmpeg.a src/lib/ffmpeg/libffmpeg_util.a src/lib/nfs/libnfs.a src/lib/yajl/libyajl.a src/lib/crypto/libcrypto_md5.a src/input/libinput_api.a src/pcm/libpcm.a src/tag/libtag.a src/time/libtime.a src/archive/libarchive_glue.a src/archive/plugins/libarchive_plugins.a src/archive/libarchive_api.a src/output/liboutput_glue.a src/output/liboutput_registry.a src/output/plugins/liboutput_plugins.a src/lib/pipewire/libpipewire.a src/lib/pulse/libpulse.a src/output/liboutput_api.a src/filter/plugins/libfilter_plugins.a src/filter/libfilter_api.a src/mixer/plugins/libmixer_plugins.a src/mixer/libmixer_api.a src/zeroconf/libzeroconf_bonjour.a src/zeroconf/avahi/libavahi.a src/filter/libfilter_glue.a src/mixer/libmixer_glue.a src/decoder/libdecoder_glue.a src/decoder/plugins/libdecoder_plugins.a src/lib/xiph/libflac.a src/lib/xiph/libxiph.a src/lib/xiph/libvorbis.a src/lib/xiph/libogg.a src/lib/crypto/libcrypto_base64.a src/decoder/libdecoder_api.a src/encoder/libencoder_glue.a src/encoder/plugins/libencoder_plugins.a src/playlist/libplaylist_glue.a src/playlist/plugins/libplaylist_plugins.a src/playlist/libplaylist_api.a src/db/libdb_glue.a src/db/plugins/libdb_plugins.a src/lib/pcre/libpcre.a src/lib/zlib/libzlib.a src/db/libdb_api.a src/storage/libstorage_api.a src/storage/libstorage_glue.a src/storage/plugins/libstorage_plugins.a src/song/libsong.a src/lib/systemd/libsystemd.a src/lib/sqlite/libsqlite.a /usr/lib/libdbus-1.so /usr/lib/libfmt.so /usr/lib/liburing.so /usr/lib/libavutil.so /usr/lib/libavformat.so /usr/lib/libavcodec.so /usr/lib/libavfilter.so /usr/lib/libpcre2-8.so /usr/lib/libsqlite3.so /usr/lib/libchromaprint.so /usr/lib/libicui18n.so /usr/lib/libicuuc.so /usr/lib/libicudata.so -pthread /usr/lib/libupnp.so /usr/lib/libixml.so /usr/lib/libcurl.so /usr/lib/libexpat.so /usr/lib/libcdio_paranoia.so /usr/lib/libcdio_cdda.so /usr/lib/libcdio.so -lm /usr/lib/libmms.so /usr/lib/libnfs.so /usr/lib/libyajl.so /usr/lib/libasound.so /usr/lib/libsamplerate.so /usr/lib/libsoxr.so /usr/lib/libid3tag.so /usr/lib/libz.so -lbz2 /usr/lib/libiso9660.so /usr/lib/libzzip.so /usr/lib/libao.so /usr/lib/libjack.so /usr/lib/libpipewire-0.3.so /usr/lib/libpulse.so /usr/lib/libshout.so /usr/lib/libopenal.so /usr/lib/libavahi-common.so /usr/lib/libavahi-client.so /usr/lib/libFLAC.so /usr/lib/libfluidsynth.so /usr/lib/libaudiofile.so -lfaad /usr/lib/libgme.so -lmad /usr/lib/libmikmod.so /usr/lib/libmodplug.so -lmpcdec /usr/lib/libmpg123.so /usr/lib/libopus.so /usr/lib/libsidplayfp.so -fopenmp /usr/lib/libsndfile.so /usr/lib/libogg.so /usr/lib/libvorbis.so /usr/lib/libwavpack.so /usr/lib/libWildMidi.so /usr/lib/libvorbisenc.so -lmp3lame /usr/lib/libtwolame.so /usr/lib/libmpdclient.so /usr/lib/libsystemd.so -Wl,--end-group In member function ‘__ct ’, inlined from ‘__ct ’ at ../src/util/AllocatedString.hxx:159:30, inlined from ‘soundcloud_resolve’ at ../src/playlist/plugins/SoundCloudPlaylistPlugin.cxx:56:29, inlined from ‘TranslateSoundCloudUri’ at ../src/playlist/plugins/SoundCloudPlaylistPlugin.cxx:102:32, inlined from ‘soundcloud_open_uri’ at ../src/playlist/plugins/SoundCloudPlaylistPlugin.cxx:261:37: ../src/util/AllocatedString.hxx:58:20: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 58 | *p = SENTINEL; | ^ ../src/util/AllocatedString.hxx:53:24: note: at offset [-9223372036854775808, -1] into destination object of size [9, 9223372036854775807] allocated by ‘operator new []’ 53 | :value(new value_type[TotalSize(src) + 1]) | ^ /usr/bin/ld: warning: libvmaf.so.1, needed by /usr/lib/libavfilter.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to `vmaf_model_destroy' /usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to `vmaf_close' /usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to `vmaf_feature_dictionary_set' /usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to `vmaf_init' /usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to `vmaf_model_feature_overload' /usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to `vmaf_picture_unref' /usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to `vmaf_write_output' /usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to `vmaf_score_pooled' /usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to `vmaf_read_pictures' /usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to `vmaf_model_load' /usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to `vmaf_model_load_from_path' /usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to `vmaf_use_features_from_model' /usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to `vmaf_picture_alloc' /usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to `vmaf_use_feature' collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. ==> ERROR: A failure occurred in build(). Aborting... error: failed to build 'mpd-git-0.23.13.792.gba2df05fb-2': error: packages failed to build: mpd-git-0.23.13.792.gba2df05fb-2 [1] https://aur.archlinux.org/account/mackel/ [2] https://aur.archlinux.org/pkgbase/mpd-git/

1 year, 7 months

Re: [aur-requests] [PRQ#10670] Deletion Request for dune

by Jakob Gahde

Hi Bruno, first of all, thanks for that elaborate response! It seems that when I looked at your PKGBUILD, I let myself be guided to premature assumptions by the similar structure and also the version adjustment in provides in particular, I’m sorry about that! It was some of the details like the OPAMROOT environment variable or the use of install instead of mkdir that really made me suspicious there, but maybe I’m just too accustomed to the somewhat poor quality standard in the AUR that you mentioned. What you say about those build system quirks is really true, too. I’ve packaged more than a few pieces of OCaml software at this point, and I can tell you a thing or two about all the crazy stuff that these folks like to come up with. Also thanks for pointing me to that FOSDEM talk, it’s pretty fantastic (and painfully accurate)! As for the credits, its not so much the attribution that really counts for me there, it’s mostly about time investment and transparency. Maintaining a package means taking responsibility and investing effort in it; as you learned yourself, figuring out how to package dune is a great way to get rid of your free time, and the idea of having someone silently run off with the work that came out of that felt like having someone trample on that precious free time. That’s basically what I was referring to when I said that I left that anonymous line in ocp-build “just to let people know that I’m not the only person who ever invested time in that package”: There was also someone else who was once willing to take the responsibility for that package, even though they didn’t have to. Since in this case it turned out that the time was in fact invested twice, though, I don’t really care about it here anymore. So now on to the technical side. 1. Personally I used to be a big fan of namcap myself, but over time I’ve come to take it’s output with a grain of salt. It gets a lot of the basics right and is very helpful for some easy-to-miss stuff (like a dependency on glibc), but it tends to miss or get wrong a lot of the more “advanced” aspects. I’ve been planning for ages to look into contributing to it, but to this day I’m not even sure where it’s maintained :/ 2. Thanks for that issue about OPAM usage in dune, I wasn’t aware of it since it was opened after I initially created the jbuilder package. 3. ocaml-findlib is something that OCaml software uses to, well, find libraries. Since it provides wrappers around the compiler and such, older build systems like OASIS also rely on it for the build procedure and installation, but newer OCaml build systems like dune and some others (don’t remember exactly which ones) can do much of their work without it, despite still integrating with it. Hence why it’s in fact an optional dependency for dune and not a hard dependency. Most of the current packaging guidelines for OCaml actually seem to be geared towards software using OASIS as build system, and I suppose that’s the main reason for why it’s in makedepends, even though OASIS seems to be on a decline. But I have to admit that I didn’t exactly pay a lot of attention to this whole affair myself, and I should probably have a proper look at it. Maybe I could also update the wiki page while I’m at it, the last meaningful changes were made way back in 2012. Since “package guidelines” has a somewhat official sound to it, do you happen to know whether the contents of these pages are coordinated somehow or whether they are basically community-maintained? 4. Thanks for pointing out that problem when comparing versions, I never noticed that. As for my opinion, I think moving the package to community is a good opportunity to “fix” the versioning. We can notify people as you suggested, and the ones who don’t get the notification will still see a message à la “warning: dune: local (1.0+beta17-1) is newer than community (1.0b17-1)” when performing sysupgrades. As for ocp-build, it’s actually not all that difficult to build; it comes pretty close to './configure; make; make install' and the patch that you saw (which was necessary because the program tried to use terminfo functions without linking to libtinfo) is no longer required in the current version (maybe related to the added dependency on cmdliner?). Also, I’m actually not an OCaml developer myself either, but it just so happened that I wanted to use some software written in OCaml at some point, and that software happened to have some dependencies that had some dependencies that had some dependencies… and in the end I somehow ended up with 100+ OCaml packages and a lot of unexpected experience under my belt. That’s why that “QIIME dependency hell” slide in the FOSDEM talk felt somewhat familiar to me, even though it’s all OCaml in my case (which doesn’t necessarily make it any better lol). Lastly, thanks a lot for offering to sponsor me! Right now I still have a backlog of package updates that I want to get done on the AUR (thanks to me failing to adjust to my new full-time university schedule before it was too late), but I’ll make sure get back to your offer once that is back to normal. Have a nice day Jakob On Mon, 19 Feb 2018, at 18:44, Archange wrote: > Hi, > > Thanks for your email and sorry about this… This is quite a long story, > but those deletion notifications (as a matter of fact, 5 packages from > the `(ocaml-)merlin` dependency tree are “affected”) now remind me I was > only half-way through before I had to go… > > First thing is that I did not use AUR PKGUILDs for any of those packages > for two reasons: > > 1. I missed them in the first place, because I did look for > `ocaml-merlin` only /sigh/ —especially to end up with the name `merlin` > for the package after more carefully looking at OCaml packaging > guidelines— and then was clearly tired (did that between 10 p.m. and 2 > a.m., on and before a day I had other things to do) and just started to > recursively package anything needed I could not find in our repos, > without checking at AUR once again… This has actual consequences that I > need to address btw (regarding version numbers). > > 2. I mostly never use AUR PKGBUILDs anyway when pushing to [community], > unless they are things that are hard to figure when trying to build, > because their quality is generally poor. > > Now, I actually spent almost 4 hours for writing those PKGBUILDs > “correctly” (in the sense of having them build in a [community]-suitable > way), so I can definitively agree that it is not just a `./configure; > make; make install` thing (and even worse than that, there is actually a > `./configure` in `merlin`, but it is not `autotools` one… And most > mjambon’s libs had strange `make` targets and no install ones… since his > switch to `dune/jbuilder` for his projects. Reminded me of that FOSDEM > talk on “How to make package managers cry”…). > > So actually finding the AUR package (well finding them earlier, because > I did find `dune` afterwards and wrote somewhere I should look at that) > would have helped me a lot, because that was quite painful indeed > (especially finding how to pass flags during `make` and which ones where > supported). That being said, I’m perfectly fine in adding you to the > “credits”, and by the way don’t really care about that tag (I only care > about the `Maintainer` tag being accurate, because it is useful for some > tools like repology). > > On the technical side of things, you’ve raised some concerns: > > 1. Why is there no dependency on `ocaml`? > 2. Why is there no dependency on `opam`? > 3. Why is there no optional runtime dependency on `ocaml-find`? > 4. What is going on with the versioning scheme? > > And here are some answers: > > 1. That’s a perfectly valid concern. I admit having not given many > thought about it and mostly went with what `namcap` returned. I cannot > find a case where it would be useful without it, so I’m adding it to > dependencies, thanks. > > 2. While I was working on the packaging of `dune`, I did not noticed it > needed `opam` for some actions. I did when trying to build mjambon’s > libs, and he kindly sent me toward > https://github.com/ocaml/dune/issues/372 (from > https://github.com/mjambon/easy-format/pull/20, which is something I’ve > also forgotten to do for the other ones). So I hope for `opam` to not be > required anymore in the future, at least for my use of `dune`, but in > the meantime I will add it to the dependencies. > > 3. Well I did not thought about putting it there since it was already in > my `makedepends` array for my mjambon’s libs PKGBUILDs (as per OCaml > packaging guidelines). But now that I look at it again, those > `makedepends` arrays are basically `(ocaml-findlib dune opam)`, so > moving this as well as `opam` to `dune` dependencies totally makes > sense. Hard dependency, that is. > > 4. That’s a more though point. Your (well actually upstream’s) > versioning scheme is actually not valid for a PKGBUILD, because > `1.0+beta17` is in fact an higher version number than `1.0`, and thus > would have required an epoch when updating to the final release. That > being said, since your package does exist, this also means my version > number is not higher than AUR’s one, which is not necessarily a good > practice (and actually they are similar issues because of pkgrel for the > other ones). They are two solution, with one minor variation: either we > tell people to manually install the [community] one over the AUR one, or > we add an `epoch`, which can be then done either now (and then keeping > “my” —as a matter of fact the standard for this kind of things— > versioning scheme) or when 1.0 final is released by moving to your > versioning scheme. Any opinion on this? > > BTW, you have also made me notice I forgot to enable tests in `dune` and > `cppo` (but I did latter in `merlin` and `ocaml-*`). So at this point > you have definitively earned your `Contributor` tag if you care about > it. ;) (And please read below if you even want the `Maintainer` one, > that’s possible) > > And thanks for mentioning `ocp-build`, because as a matter of fact in my > attempt to package `merlin`, I was also after `ocp-indent` and thus > `ocp-build`, already added them in my staging directory and thus missed > to check AUR again, but stopped there because of time. Seems like > `ocp-indent` is not there, but I’m already interested by your > `ocp-build` would it be just because it carry a patch with it, > containing something I would probably not have thought about, or its > clear indication that I will have to look carefully at that > `./configure`… ;) > > And for what is worth, I’m actually not doing any development in OCaml, > but we have very recently switched to it for some algorithm teaching in > France (from caml-light, for which we have been the only users I believe > for the past 20 years…), and for some reasons not relevant for this > discussion I needed proper support for OCaml in my editor (and the > student’s ones). So that’s why I’m packaging all this, but otherwise > don’t care at all about OPAM and such because we are not going to use > anything outside of the standard. But if you are interested in packaging > them and maybe other things for ArchLinux, you might consider applying > for TU in which case I’d be OK to be your sponsor, since you will likely > do a better maintainer than I do for those OCaml packages, at least on > the ocaml building side. :) > > Regards, > Bruno > > P.S.: I have exactly the same issue as you when it comes to people > interpreting my mood by reading my writing, so I totally understand > that. Hint: I’ve learned that adding smileys, even if it might not look > very “professional“, helps a lot. ;) > > Le 19/02/2018 à 17:03, Jakob Gahde a écrit : > > FWIW, great to have this in community. Not so great that a deletion request is the first thing that informs me about this and even less so to have somebody else run off with the work that I put into figuring out how to make this piece of software install correctly and only add a few mostly cosmetic changes for good measure, without even a mention. The process isn’t just './configure; make; make install'; at least for me it took a while to figure everything out, and I’m not exactly a newbie to all the crazy stuff that OCaml people tend to use in their build infrastructure. > > While I’m at it, I wonder what the purpose is behind not depending on OCaml for a tool aimed at building OCaml software. Secondly, OPAM is run automatically on most invocations of dune to my knowledge, so I believe depending on it is somewhat reasonable. And lastly, the sources of dune happen to mention in plain English that dune can make use of ocamlfind as an optional runtime dependency[1]. So much for my reasoning on the dependencies, I would have been happy to explain this earlier if someone had let me. > > Forgive me if I’m a little upset, but when the new community package even goes out of it’s way to provide compatibility with the versioning scheme I used on the jbuilder package before it was renamed to dune, I just don’t understand why not even a little heads-up à la “BTW this package is now in community” was possible. Personally, I even left a contributor line saying “Your Name <youremail(a)domain.com>” untouched in one of the packages I adopted, just to let people know that I’m not the only person who ever invested time in that package (namely ocp-build). > > > > tl;dr I know that in written form my thoughts tend to come off as being more furious than I actually am, and while I do in fact not like what I believe went on, what I really want you, Bruno, to take away from this is just „Please be a little more communicative in the future” :) > > > > Have a nice day > > Jakob Gahde aka J5lx > > > > [1] https://github.com/ocaml/dune/blob/1.0%2Bbeta17/jbuilder.opam#L17-L22 > > > > On Mon, 19 Feb 2018, at 15:34, notify(a)aur.archlinux.org wrote: > >> mis [1] filed a deletion request for dune [2]: > >> > >> in [community] > >> https://www.archlinux.org/packages/community/x86_64/dune/ > >> > >> [1] https://aur.archlinux.org/account/mis/ > >> [2] https://aur.archlinux.org/pkgbase/dune/

7 years, 5 months

Aur-requests search results for query "Deletion request for pkgbase"