Package Details: wingide 7.2.4.0.1-1

Git Clone URL: https://aur.archlinux.org/wingide.git (read-only, click to copy)
Package Base: wingide
Description: Wing IDE Professional is the full-featured Python IDE for professional programmers.
Upstream URL: http://www.wingware.com
Licenses: custom
Submitter: None
Maintainer: None
Last Packager: thotypous
Votes: 46
Popularity: 0.000000
First Submitted: 2008-03-13 17:00
Last Updated: 2020-08-22 23:39

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 ... Next › Last »

greyltc commented on 2016-05-10 11:40

Oops. I thought pacman took pkgver to be more important than epoch when deciding when to upgrade. So I guess there are two possible solutions to the problem I've created here:
A) stay on epoch 3 forever, preserving automatic upgrades
or
B) remove epoch from the PKGBUILD now, bringing the package's version number back to the way it should be, thus breaking automatic updates. I'd add a comment here instructing users to "downgrade" to the latest version. Users would get an upgrade nag message every time they launch the IDE and eventually they'll come here wondering why I haven't upgraded the package and read my downgrade instructions to get back on track.

I lean towards option B.

von commented on 2016-05-10 10:49

It goes against the versioning conventions. You have _wingrel variable, you should just add patch level there (1->1p1, 1p1->1p3, for example). Resulting package already has an upstream rel (albeit separated from the upstream version by a dot) value in its version anyway. Ideally epoch should not be used at all, but now there is no going back (since omitting it will make newer versions lesser than epoch'ed ones).

Epoch approach will stop working the next minor upstream version you release (say, it'll be 5.1.12-1 with no patches, you release it as 5.1.12.1-1, and it's considered 0:5.1.12.1-1 by the package manager, which is lower than current 3:5.1.11.1-1).

greyltc commented on 2016-05-10 10:20

My plan has been to bump epoch whenever I add a new patch from wingware[1], bump pkgrel for any changes I might have to make to the PKGBUILD and keep pkgver in sync with the release version number. Do you think that makes sense?

Wingware has released a few patches recently (they don't change the release version number for these), that's why you've noticed me bumping epoch lately for those.

[1]: https://wingware.com/downloads/wingide/5.1.11-1/patches

von commented on 2016-05-10 07:49

Okay, so just out of curiosity, I'd like to ask this question: why do you bump epoch every time a minor update to the package happens? pkgrel is meant for this, by convention epoch is supposed to change only when the versioning of the package itself changes.

DescartesHorse commented on 2016-04-18 00:47

I'll email this through as well, but just bumping this to the latest version as available for the last 2 days :)


Subject: [PATCH] Increment to version 5.1.11-1 Update checksums and version
number

---
PKGBUILD | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/PKGBUILD b/PKGBUILD
index 0bb191c..ec02d4b 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -1,7 +1,7 @@
# Maintainer: Grey Christoforo <first name [at] last name [dot] net>

pkgname=wingide
-_wingver=5.1.10
+_wingver=5.1.11
_wingrel=1
pkgver=$_wingver.$_wingrel
pkgrel=1
@@ -25,8 +25,8 @@ source_x86_64=("http://wingware.com/pub/$pkgname/$_wingver/$pkgname-$_wingver-$_
source_i686=("http://wingware.com/pub/$pkgname/$_wingver/$pkgname-$_wingver-$_wingrel-i386-linux.tar.gz" $_wingpatch_i686)
depends=('hicolor-icon-theme' 'libpng' 'python2' 'xdg-utils')
options=(!strip !emptydirs)
-md5sums_i686=('b85ac4315ad4bc846e4fb52d6e23fa6a')
-md5sums_x86_64=('dc10ec69e4ae02af8fa895b46d780e41')
+md5sums_i686=('392b8f3a0e2dcb69fd2d8316bd88b028')
+md5sums_x86_64=('ddacf06b4cc9577b9b80cbbb79de2d32')
install=${pkgname}.install

prepare() {
@@ -60,4 +60,3 @@ package() {
chmod +x ${pkgdir}/opt/${pkgname}/resources/linux/desktop/install-linux-desktop.sh
# Install the LICENSE
install -D -m 644 "${pkgdir}/opt/${pkgname}/LICENSE.txt" "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
-}
--
2.8.0

greyltc commented on 2015-12-22 18:29

I've modified the PKGBUILD so that it pulls in patches from wingware.

greyltc commented on 2015-08-27 09:18

Looks like the installer has been fixed upstream.
The 5.1.7-1 release seems to be working fine for me with no changes.

bpetlert commented on 2015-08-21 11:53

@greyltc:
I fix it by add --relocatable option to suppress file list (file-list.txt) generation.
The wing-install.py script use it for uninstallation. It is not necessary for Arch package.

http://clipboard.space/clip/r9XQb9PewrIPjLpodwkb

greyltc commented on 2015-08-21 11:15

The upstream install script for 5.1.6-1 still seems to be broken. I'll wait a bit to see if they decide to fix it before I spend some time trying to fix it myself. If anyone else has a workaround/fix for the missing link:

opt/wingide/bin/2.7/src/guiutils/WGuiCppImpl/build/slib/libWGuiCppImpl.so -> libWGuiCppImpl.so.1.0.0

feel free to contribute the fix here.

Lastebil commented on 2015-08-18 19:19

5.1.6-1 is out, sha1sum on website is
32 bit: 32db90ba602897f1bd794d590dc2d33a98ff07b2
64 bit: c2fe1f3ab74e1db2d7861797f9f801ffac6f182f
(but I see you stuck to making your own md5's rather than using the sha1 from the website)

that said: currently the tarball has an error in the installer when attempting to generate the file listing that it creates, due to a linked file not existing. I think they may be updating that tarball soon to fix the error, so I am not marking it out of date at this time.

I patched my installer file by using a try/except around the clause that generates the error, I'm fairly sure this is not really the way to go and instead we should wait for upstream to issue a fixed tarball.