| Summary: | net-im/skypeforlinux: new skype for Linux alpha version | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Cănărău Constantin <canarauc> |
| Component: | Current packages | Assignee: | Raymond Jennings <shentino> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ab4bd, aldo.mazzeo, contactme, dblaci, email, kkrizka, mario.fetka, proxy-maint, robink, rossi.f, shentino, sven.koehler, wschlich |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://community.skype.com/t5/Linux/Skype-for-Linux-Alpha-and-calling-on-Chrome-amp-Chromebooks/td-p/4434299 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
net-im/skypeforlinux-1.0.1.ebuild
skype-1.1.0.21_alpha.ebuild skype-1.1.0.21_alpha.ebuild skype-1.2.0.1_alpha.ebuild skype-1.3.0.0_alpha.ebuild skype-1.5.0.3_alpha.ebuild skype-1.5.0.3_alpha.ebuild skype-1.5.0.3_alpha.ebuild |
||
|
Description
Cănărău Constantin
2016-07-14 12:14:31 UTC
No version: skypeforlinux-64-alpha.deb (In reply to Jeroen Roovers from comment #1) > No version: skypeforlinux-64-alpha.deb Yes, no version in package name. Unpacked and running version is 1.0.1 (Help -> About) Thank you! Created attachment 440726 [details]
net-im/skypeforlinux-1.0.1.ebuild
(In reply to SpikyAtLinux from comment #3) > Created attachment 440726 [details] > net-im/skypeforlinux-1.0.1.ebuild Thank you for the ebuild. Can you confirm that it is working for you ? For me "Sorry, we couldn't connect to Skype." is all I get. First, most important, my mistake: version is 1.1.0.21. Size and checksum didn't change, so it is definitely my bad. Sorry for that. All dependencies are meet. Depends: gconf-service, libasound2 (>= 1.0.16), libatk1.0-0 (>= 1.12.4), libc6 (>= 2.12), libcairo2 (>= 1.6.0), libcups2 (>= 1.4.0), libdbus-1-3 (>= 1.2.14), libexpat1 (>= 2.0.1), libfontconfig1 (>= 2.9.0), libfreetype6 (>= 2.4.2), libgcc1 (>= 1:4.1.1), libgconf-2-4 (>= 2.31.1), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.31.8), libgnome-keyring0 (>= 2.22.2), libgtk2.0-0 (>= 2.24.0), libnspr4 (>= 2:4.9-2~) | libnspr4-0d (>= 1.8.0.10), libnss3 (>= 2:3.13.4-2~) | libnss3-1d (>= 3.12.4), libpango1.0-0 (>= 1.14.0), libstdc++6 (>= 4.6), libx11-6 (>= 2:1.4.99.1), libxcomposite1 (>= 1:0.3-1), libxcursor1 (>> 1.1.2), libxdamage1 (>= 1:1.1), libxext6, libxfixes3, libxi6 (>= 2:1.2.99.4), libxrandr2 (>= 2:1.2.99.2), libxrender1, libxss1, libxtst6, gnome-keyring No output in log file $HOME/.config/skypeforlinux/logs/ Yes it´s working, I can connect an my contacts were shown, everything is working. * dependency graph for net-im/skypeforlinux-1.0.1 `-- net-im/skypeforlinux-1.0.1 ~amd64 `-- dev-libs/atk-2.18.0 (dev-libs/atk) amd64 `-- x11-libs/cairo-1.14.6 (x11-libs/cairo) amd64 `-- net-print/cups-2.1.3-r1 (net-print/cups) amd64 `-- sys-apps/dbus-1.10.8-r1 (sys-apps/dbus) amd64 `-- dev-libs/expat-2.1.1-r2 (dev-libs/expat) amd64 `-- gnome-base/gconf-3.2.6-r4 (gnome-base/gconf) amd64 `-- gnome-base/libgnome-keyring-3.12.0 (gnome-base/libgnome-keyring) amd64 [ net-im/skypeforlinux-1.0.1 stats: packages (8), max depth (1) ] Sorry now an developer is needed, I´ve only modified the ebuild. Regards No internet connection skype say and yet: lsof | grep skype | grep IPv4 skypeforl 19374 costel 77u IPv4 473582 0t0 TCP mini:37344->134.170.188.139:https (ESTABLISHED) skypeforl 19374 costel 87u IPv4 473507 0t0 TCP mini:34474->91.190.218.34:https (ESTABLISHED) skypeforl 19374 19380 costel 77u IPv4 473582 0t0 TCP mini:37344->134.170.188.139:https (ESTABLISHED) skypeforl 19374 19380 costel 87u IPv4 473507 0t0 TCP mini:34474->91.190.218.34:https (ESTABLISHED) skypeforl 19374 19381 costel 77u IPv4 473582 0t0 TCP mini:37344->134.170.188.139:https (ESTABLISHED) skypeforl 19374 19381 costel 87u IPv4 473507 0t0 TCP mini:34474->91.190.218.34:https (ESTABLISHED) skypeforl 19374 19382 costel 77u IPv4 473582 0t0 TCP mini:37344->134.170.188.139:https (ESTABLISHED) skypeforl 19374 19382 costel 87u IPv4 473507 0t0 TCP mini:34474->91.190.218.34:https (ESTABLISHED) skypeforl 19374 19383 costel 77u IPv4 473582 0t0 TCP mini:37344->134.170.188.139:https (ESTABLISHED) skypeforl 19374 19383 costel 87u IPv4 473507 0t0 TCP mini:34474->91.190.218.34:https (ESTABLISHED) skypeforl 19374 19398 costel 77u IPv4 473582 0t0 TCP mini:37344->134.170.188.139:https (ESTABLISHED) skypeforl 19374 19398 costel 87u IPv4 473507 0t0 TCP mini:34474->91.190.218.34:https (ESTABLISHED) Definitely an ISP issue. It is working on my work computer (different internet provider). Usually I don't install testing packages on it, but skype is important. Using mtr I discovered a DNS error. Setting OpenDNS or Google dns servers everything is ok. Now I am waiting for video support for skype on linux. I also belive that google-chrome or chromium should be on RDEPEND list, as basically is skype for web and it is not working, at least for me, on firefox. Thank you! *** Bug 588856 has been marked as a duplicate of this bug. *** Now it says "Version: 1.1.0.21" and file name is still the same. Maybe set version to 9999 instead? My original intention was to propose this as a different package, or a slotted version of skype, but it seems I didn't choose the words very carefully so title was changed. Right now, this alpha version has some advantages like 64 bits, no qt* dependencies, integrated interface, but also few notable disadvantages like no video support, maybe unstable. Bottom line, I believe this is not suitable replacement for skype 4.3.0.37-r5/6. At least until we get all major features available. I very much disagree. The present version in tree does not work *at all* for me, and I've filed bugs against it multiple times. As for versioning, since its known to be an alpha why not just keyword it/version tag it like any other alpha/beta package? I have nothing against 9999 version. Just to be possible to have both version installed simultaneous. I am sorry that "classic" skype does not work for you. Have you tried in a chroot ? For me, that solved the problem and is much secure way to run it. Here is my script: /usr/bin/killall -9 skype-bin &>/dev/null /usr/bin/systemd-nspawn -D /mnt/chroot32/ --bind=/tmp/.X11-unix --bind=/run/user/`id -u costel`/pulse --bind=/dev/snd --bind=/dev/video0 --bind=/etc/machine-id --user=costel --bind=/dev/shm \ --bind /usr/portage --share-system --personality=x86 --tmpfs=/tmp:size=1G env DISPLAY=:1 PULSE_SERVER=unix:/run/user/`id -u costel`/pulse/native /opt/bin/skype & Of course, instead of pulseaudio you can use apulse and chroot instead systemd-nspawn. Created attachment 441054 [details]
skype-1.1.0.21_alpha.ebuild
This is a ebuild that installs the new alpha to /opt
this ebuild ist still lacking the patch for the desktop file, the selinux profile, and the pax mods but otherwise it is working.
all the useflags selinux und pax are present but would not change anything.
it installs the new skype in a slot.
Skype for linux alpha also depends on gnome-base/libgnome-keyring and gnome-base/gnome-keyring. You might also want to add those in the ebuild. Additionally, the shortcut added to KDE menu points to a non-existing binary under /usr, whereas it should point to "/opt/bin/skypeforlinux". Created attachment 441100 [details]
skype-1.1.0.21_alpha.ebuild
thx for the info corrected.
Thanks for the ebuild! I would suggest to call the ebuild "skype-1.2_alpha-r2" (and stick with this 1.2_alpha" as Microsoft is not changing the file name for new version and thus it is pointless to suggest you are installing a particular version and you can't determine the version until you installed it *sigh* When you have to make changes to the ebuild, just increase the number of "gentoo revision number" like "ebuild skype-1.2_alpha-r3", "ebuild skype-1.2_alpha-r4" until MS decides to properly release versions... Cheers, Bjoern Created attachment 441530 [details]
skype-1.2.0.1_alpha.ebuild
i am using the rpm version infos nit the infos of the program itself i have seen more then once new rpm but same programm veriosn but binarty has different checksum so i intentionally follow the rpm version info
this ebauld saves the binary to a versioned name
I thought it would be interesting to try this, but I haven't worked with ebuilds like this before and evidently don't know how this should be done. I've put the latest skypeforlinux.ebuild in /usr/local/portage/app-misc/skypeforlinux/ Then from that directory tried ebuild skypeforlinux.ebuild merge And then got ebuild: /usr/local/portage/app-misc/skypeforlinux/skypeforlinux.ebuild: app-misc/skypeforlinux: does not follow correct package syntax If someone is kind enough to outline the proper steps, I'll give it a try. Thanks, Fred (In reply to Fred Krogh from comment #18) > I thought it would be interesting to try this, but I haven't worked with > ebuilds like this before and evidently don't know how this should be done. > I've put the latest skypeforlinux.ebuild in > /usr/local/portage/app-misc/skypeforlinux/ > Then from that directory tried > ebuild skypeforlinux.ebuild merge > And then got > ebuild: /usr/local/portage/app-misc/skypeforlinux/skypeforlinux.ebuild: > app-misc/skypeforlinux: does not follow correct package syntax > > If someone is kind enough to outline the proper steps, I'll give it a try. > Thanks, > Fred Ebuild file does not have a version. It should be: /usr/local/portage/app-misc/skypeforlinux/skypeforlinux-1.2.0.1_alpha.ebuild -1.2.0.1_alpha was missing. Then you should create the manifest file: ebuild /usr/local/portage/app-misc/skypeforlinux/skypeforlinux-1.2.0.1_alpha.ebuild manifest And finally emerge it: emerge -av skypeforlinux Side note: As long is in your local overlay and not in the official portage treeit does not matter, but the proper category is net-im, not app-misc. When it will be in the official portage tree it will matter. A lot. Created attachment 442196 [details]
skype-1.3.0.0_alpha.ebuild
updated ebuild
also create a compat link for "Help->Legal Notice" Menu Entry.
for 1.4.0.1 you can use the 1.3.0.0 ebuild Currently, there is a 1.5.0.3 RPM out. I noticed that in the ebuild here, there is missing gnome-base/gconf dependency. is anyone willing to proxy maintain this? https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers Created attachment 443896 [details]
skype-1.5.0.3_alpha.ebuild
new version also added deep on gconf
Created attachment 443898 [details]
skype-1.5.0.3_alpha.ebuild
disabled all not used features and corrected desktop file
Created attachment 443900 [details]
skype-1.5.0.3_alpha.ebuild
damm typo
(In reply to Pacho Ramos from comment #23) > is anyone willing to proxy maintain this? > https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers Yes. the 1.5.0.3 ebuild can be used for the actual 1.7.0.1 version. I've just pushed 1.7.0.1 to the tree... https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2b453e9de064709a7e3fa21d74b2cb5f2da05e4f ...BUT! I (once again *sigh*!) forgot to add attributions for the ebuild, in this case to Mario Fetka :( I'm sorry! Mario and Raymond, is any one of you guys willing to proxy-maintain the new generation of this package? Whoa, looks like version 1.7.0.1 is being preempted by the version 4.3.0.37 that was already in the tree. And yes I'd like to proxymaint this packages. Mario is more than welcome to assist if they like. Btw, I'd also like to suggest that this version and the previous version be slotted, if that can work? There's still some functionality in the old one not present in the new one. (In reply to Raymond Jennings from comment #31) > Btw, I'd also like to suggest that this version and the previous version be > slotted, if that can work? > > There's still some functionality in the old one not present in the new one. I already initially committed 1.7.0.1 with SLOT=1 whereas 4.3.0.37 has SLOT=0. I did add a blocker to 1.7.0.1 for SLOT==0, though. Do you suggest to remove the blocker? (In reply to Raymond Jennings from comment #30) > [...] > And yes I'd like to proxymaint this packages. Mario is more than welcome to > assist if they like. I've added you to metadata.xml. Welcome! :) (In reply to Wolfram Schlich from comment #32) > (In reply to Raymond Jennings from comment #31) > > Btw, I'd also like to suggest that this version and the previous version be > > slotted, if that can work? > > > > There's still some functionality in the old one not present in the new one. > > I already initially committed 1.7.0.1 with SLOT=1 whereas 4.3.0.37 has > SLOT=0. > I did add a blocker to 1.7.0.1 for SLOT==0, though. > Do you suggest to remove the blocker? I don't know how slotting works (yet), so I'm not sure. I want to do whatever will accomplish: 1. Having both skype versions installed at the same time 2. Turfing out any prior versions/revisions I'm thinking of doing the following: 1. Marking 1.7.0.1 as SLOT="1.7.0.1" 2. Marking 4.3.0.37 as SLOT="4.3.0.37" 3. Revbumping both upstream versions 4. Removing ebuilds revisions that aren't slotted accordingly 5. Pmasking the removed ebuilds Can I legally do this without violating gentoo policy? I'm still kinda green with both slotting and pmasking. (In reply to Raymond Jennings from comment #34) > (In reply to Wolfram Schlich from comment #32) > > (In reply to Raymond Jennings from comment #31) > > > Btw, I'd also like to suggest that this version and the previous version be > > > slotted, if that can work? > > > > > > There's still some functionality in the old one not present in the new one. > > > > I already initially committed 1.7.0.1 with SLOT=1 whereas 4.3.0.37 has > > SLOT=0. > > I did add a blocker to 1.7.0.1 for SLOT==0, though. > > Do you suggest to remove the blocker? > > I don't know how slotting works (yet), so I'm not sure. > > I want to do whatever will accomplish: > > 1. Having both skype versions installed at the same time > 2. Turfing out any prior versions/revisions > > I'm thinking of doing the following: > > 1. Marking 1.7.0.1 as SLOT="1.7.0.1" > 2. Marking 4.3.0.37 as SLOT="4.3.0.37" > 3. Revbumping both upstream versions > 4. Removing ebuilds revisions that aren't slotted accordingly > 5. Pmasking the removed ebuilds > > Can I legally do this without violating gentoo policy? I'm still kinda > green with both slotting and pmasking. I don't understand why slots should play into this at all. See slotting page in devmanual https://devmanual.gentoo.org/general-concepts/slotting/index.html: Packages can support having multiple versions installed simultaneously. This is useful for libraries which may have changed interfaces between versions — for example, the gtk+ package can install both versions 2.24 and 3.6 in parallel. This feature is called slotting. Most packages have no need for slotting. When upstream is doing something silly and downgrading version number, and in this case due to a different implementation I question whether re-using the same package name is correct to begin with. But even so, why isn't the newer version simply exposed using a higher version number, e.g 2016.1.7.0.1? As the saying goes, entia non sunt multiplicanda praeter necessitatem (In reply to Kristian Fiskerstrand from comment #35) > When upstream is doing something silly and downgrading version number, and > in this case due to a different implementation I question whether re-using > the same package name is correct to begin with. This would of course then refer to e.g net-im/skype-alpha (or whatever the long term name is expected to be), package mask the outgoing version and lastriting it for removal. (In reply to Kristian Fiskerstrand from comment #36) > (In reply to Kristian Fiskerstrand from comment #35) > > > When upstream is doing something silly and downgrading version number, and > > in this case due to a different implementation I question whether re-using > > the same package name is correct to begin with. > > This would of course then refer to e.g net-im/skype-alpha (or whatever the > long term name is expected to be), package mask the outgoing version and > lastriting it for removal. Not in this case. The old version of skype still works and has fundamentally different functionality. As a matter of fact, I am presently using both it and the alpha version right now, and they happen to have a synergy when used together, believe it or not. (In reply to Raymond Jennings from comment #37) > (In reply to Kristian Fiskerstrand from comment #36) > > (In reply to Kristian Fiskerstrand from comment #35) > > > > > When upstream is doing something silly and downgrading version number, and > > > in this case due to a different implementation I question whether re-using > > > the same package name is correct to begin with. > > > > This would of course then refer to e.g net-im/skype-alpha (or whatever the > > long term name is expected to be), package mask the outgoing version and > > lastriting it for removal. > > Not in this case. The old version of skype still works and has > fundamentally different functionality. > That is arguing the case even further for a separate package name I'd tend to agree. Thing is I'm not sure that upstream will keep calling it "alpha". Any suggestions what to call it? The "long term name" might not be advisable to be labelled as "alpha" since I doubt its meant to stay that way by upstream. I'd rather keep them slotted with the same name though at this point because they serve the exact same role. (In reply to Raymond Jennings from comment #39) > I'd tend to agree. > > Thing is I'm not sure that upstream will keep calling it "alpha". > > Any suggestions what to call it? Unless there are other ideas (I don't use skype so don't follow naming and news on it too much), "-ng" can be an alternative (next generation) I would actually vote for using slots, with p.mask for the new version. Also, remember that slots can be strings, not only numbers. AFAIU the 'alpha' Skype is going to become mainstream at some point, and we will want to remove the 'classic' variant. In this case, it really makes no sense to invent a new name, then either do pkgmoves, or force people to switch back manually. And I strongly oppose inventing custom names that in no way match upstream naming. (In reply to Michał Górny from comment #41) > I would actually vote for using slots, with p.mask for the new version. > Also, remember that slots can be strings, not only numbers. > > AFAIU the 'alpha' Skype is going to become mainstream at some point, and we > will want to remove the 'classic' variant. In this case, it really makes no > sense to invent a new name, then either do pkgmoves, or force people to > switch back manually. > > And I strongly oppose inventing custom names that in no way match upstream > naming. I agree with this, but I also want to emphasize that the "classic" version is presently still useful. Until such time as microsoft blacklists it, I'm keeping it around and running it and the alpha version at the same time. (In reply to Michał Górny from comment #41) > I would actually vote for using slots, with p.mask for the new version. > Also, remember that slots can be strings, not only numbers. p.masking 1.7-alpha would be ok, also renaming SLOT=1 to SLOT=alpha. If the two versions (4.3-classic + 1.7-alpha) don't have file collisions, we could also remove the blocker (!${CATEGORY}/${PN}:0) I added to the 1.7 ebuild. Opinions? > AFAIU the 'alpha' Skype is going to become mainstream at some point, and we > will want to remove the 'classic' variant. In this case, it really makes no > sense to invent a new name, then either do pkgmoves, or force people to > switch back manually. > > And I strongly oppose inventing custom names that in no way match upstream > naming. That were the reasons for my decision to keep the current name. Oh, sorry, I didn't notice they rebooted versioning. In this case, split packages might be cleaner indeed. Alternatively, you could alter one of the versions, e.g. make classic 0.4... So people won't be downgrading to the new version ;-). At least in PM terms. I'm not of the opinion that we should screw with upstream version numbers. That way lies madness. What if we split it into two different packages and added a conditional news item that alerts users of the currently named package? Upstream calls it "skypeforlinux" and that's the name of the executable, so if we wanted to give it a new name I'd vote for that one. So how about we split the package, pmask the 1.7.0.1 version with a note that that version is renamed, and spit out a NEWS to people using skype that if they want the linux alpha version they should install "skypeforlinux" instead? I only know how to pmask though, NEWS bits are beyond my ken right now. My only real concern with renamed forks is lack of notice to downstream. I also think that new package name (skypeforlinux or whatever) it is the best way. Imagine my surprise today when, after I deleted skypeforlinux from my local overlay, I wanted to install skype-1.7.0 from portage... on a NOMULTILIB profile. Yep, old skype is 32 bits only, and new one 64bits only, so: These are the packages that would be merged, in order: [ebuild N #] net-im/skype-1.7.0.1:1::gentoo 0 KiB Total: 1 package (1 new), Size of downloads: 0 KiB The following mask changes are necessary to proceed: (see "package.unmask" in the portage(5) man page for more details) # required by skype:1 (argument) # /usr/portage/profiles/features/64bit-native/package.mask: # AMD64 Team <amd64@gentoo.org> # Mask packages that rely on amd64 multilib =net-im/skype-1.7.0.1 NOTE: The --autounmask-keep-masks option will prevent emerge from creating package.unmask or ** keyword changes. make no sense, right ? After I copied and renamed the version from portage in my local overlay, I could update it and it's working flawless. (In reply to Raymond Jennings from comment #45) > I'm not of the opinion that we should screw with upstream version numbers. > That way lies madness. > > What if we split it into two different packages and added a conditional news > item that alerts users of the currently named package? Not worthy of a news item, but you can add elog messages in the old branch First thing: thanks for this ebuild :) Second: is it possible to bump to 1.8, and somehow handle the nomultilib mask (both on hardened and non-hardened)? What's up with multilib?! I don't get it... I checked all the binary executables and libraries and all were 64-bit.
I didn't check whether KEYWORDS="[...] ~x86" makes any sense at all when I took the ebuild from Mario (and it doesn't *sigh*), therefore I'll remove ~x86 again.
So the majority of people in here seems to second a split of the current package "skype" in "skype" (classic, as it was before) and "skypeforlinux" (alpha).
Also, revbumping "skype" (classic) and adding some elog messages that notice people about the new alpha with a different package name ("skypeforlinux") seems to be a good idea.
I'll proceed with these steps when I don't receive objections until end of wk38 :)
Cheers,
Wolfram
(In reply to Wolfram Schlich from comment #49) > What's up with multilib?! I don't get it... I checked all the binary > executables and libraries and all were 64-bit. > > I didn't check whether KEYWORDS="[...] ~x86" makes any sense at all when I > took the ebuild from Mario (and it doesn't *sigh*), therefore I'll remove > ~x86 again. Would seem to be a good idea if the alpha version won't run on anything but amd64. > So the majority of people in here seems to second a split of the current > package "skype" in "skype" (classic, as it was before) and "skypeforlinux" > (alpha). This has my direct approval. > Also, revbumping "skype" (classic) and adding some elog messages that notice > people about the new alpha with a different package name ("skypeforlinux") > seems to be a good idea. *thumbs up* > I'll proceed with these steps when I don't receive objections until end of > wk38 :) Awesome. > Cheers, > Wolfram I only pmainted this package because I don't want it to languish without a maintainer. But if someone else can do a better job I don't mind the help. The problem is that the package "net-im/skype" is masked on nomultilib profiles. The mask should be limited to the old version slot. Anyway, if the name of new skype package is going to be changed to skypeforlinux, the nomultilib problem will be automatically fixed. Thanks Whoever does the commits suggested by wschlich, feel free to add an Acked-by: Raymond Jennings <shentino@gmail.com> i gave up to become a dev long time ago so no i don't want to become a proxy maintainer. (this is the wrong place for my frustration) yes both client can stay on the system so the block on the old verison can be removed the ~x86 was an oversight by me (MS will relase a 32bit build after the final release, hope so) (In reply to Raymond Jennings from comment #52) > Whoever does the commits suggested by wschlich, feel free to add an > Acked-by: Raymond Jennings <shentino@gmail.com> Raymond, I checked the skypeforlinux binary and libs for dependencies and came up with the following list of packages to depend upon (in contrast to skype classic): RDEPEND="virtual/ttf-fonts !net-im/skype:1 dev-libs/atk dev-libs/expat dev-libs/glib:2 dev-libs/nspr dev-libs/nss gnome-base/gconf:2 media-libs/alsa-lib media-libs/fontconfig:1.0 media-libs/freetype:2 net-print/cups sys-apps/dbus sys-devel/gcc sys-libs/glibc x11-libs/cairo x11-libs/gdk-pixbuf:2 x11-libs/gtk+:2 x11-libs/libX11 x11-libs/libXcomposite x11-libs/libXcursor x11-libs/libXdamage x11-libs/libXext x11-libs/libXfixes x11-libs/libXi x11-libs/libXrandr x11-libs/libXrender x11-libs/libXScrnSaver x11-libs/libXtst x11-libs/pango" Any objections? If not, I'll commit the new package with an Acked-by: reference to you :) (In reply to Wolfram Schlich from comment #55) > (In reply to Raymond Jennings from comment #52) > > Whoever does the commits suggested by wschlich, feel free to add an > > Acked-by: Raymond Jennings <shentino@gmail.com> > > Raymond, I checked the skypeforlinux binary and libs for dependencies and > came up with the following list of packages to depend upon (in contrast to > skype classic): > > RDEPEND="virtual/ttf-fonts > !net-im/skype:1 > dev-libs/atk > dev-libs/expat > dev-libs/glib:2 > dev-libs/nspr > dev-libs/nss > gnome-base/gconf:2 > media-libs/alsa-lib > media-libs/fontconfig:1.0 > media-libs/freetype:2 > net-print/cups > sys-apps/dbus > sys-devel/gcc > sys-libs/glibc > x11-libs/cairo > x11-libs/gdk-pixbuf:2 > x11-libs/gtk+:2 > x11-libs/libX11 > x11-libs/libXcomposite > x11-libs/libXcursor > x11-libs/libXdamage > x11-libs/libXext > x11-libs/libXfixes > x11-libs/libXi > x11-libs/libXrandr > x11-libs/libXrender > x11-libs/libXScrnSaver > x11-libs/libXtst > x11-libs/pango" > > Any objections? > > If not, I'll commit the new package with an Acked-by: reference to you :) By all means, proceed. This really does smell like it needed a new name. The architecture is fundamentally different from classic skype. Remove the block on net-im/skype though if it prevents usage of both versions. I find it useful to run both at the same time. If you have concerns that non-experts shouldn't try it, use an ewarn. Also, make sure SLOT="0". With a new package name we don't need skype to be slotted anymore. (In reply to Wolfram Schlich from comment #55) > sys-devel/gcc Are you convinced it needs the compiler at runtime? > sys-libs/glibc No other libc will work? (In reply to Michał Górny from comment #57) > (In reply to Wolfram Schlich from comment #55) > > sys-devel/gcc > > Are you convinced it needs the compiler at runtime? > > > sys-libs/glibc > > No other libc will work? Not to mention that both of these dependencies are part of @system (which every package outside of @system has an implicit dependency on), and per the devmanual, should not be dependencies unless specific versions are required. (In reply to Michał Górny from comment #57) > (In reply to Wolfram Schlich from comment #55) > > sys-devel/gcc > > Are you convinced it needs the compiler at runtime? > > > sys-libs/glibc > > No other libc will work? This is what objdump tells me about the NEEDED libraries for /opt/skypeforlinux/skypeforlinux: libc.so.6 libgcc_s.so.1 libstdc++.so.6 This is what files it resolves to on my system: libc.so.6: /lib64/libc.so.6 libgcc_s.so.1: /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1 libstdc++.so.6: /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6 Are there any other providers for these files which we can be *sure* they'll work? (In reply to Raymond Jennings from comment #56) > [...] > Remove the block on net-im/skype though if it prevents usage of both > versions. I find it useful to run both at the same time. If you have > concerns that non-experts shouldn't try it, use an ewarn. I already changed the blocker to "!net-im/skype:1" so it blocks "net-im/skype-1.7.0.1" that I committed before, but not skype classic. > Also, make sure SLOT="0". With a new package name we don't need skype to be > slotted anymore. I already took care of that :-) (In reply to Wolfram Schlich from comment #59) > (In reply to Michał Górny from comment #57) > > (In reply to Wolfram Schlich from comment #55) > > > sys-devel/gcc > > > > Are you convinced it needs the compiler at runtime? > > > > > sys-libs/glibc > > > > No other libc will work? > > This is what objdump tells me about the NEEDED libraries for > /opt/skypeforlinux/skypeforlinux: > > libc.so.6 > libgcc_s.so.1 > libstdc++.so.6 > > This is what files it resolves to on my system: > > libc.so.6: /lib64/libc.so.6 > libgcc_s.so.1: /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1 > libstdc++.so.6: /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6 > > Are there any other providers for these files which we can be *sure* they'll > work? Right, I just realized that this is upstream binary that we can't rebuild. Go ahead and leave the dependencies. =net-im/skypeforlinux-1.8.0.2 is in Portage: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3b8777958b6d3d186986205015e5cdb7be81fb45 :-) I'll now remove =net-im/skype-1.7.0.1:1. Thanks everyone! A JavaScript error occurred in the main process
Uncaught Exception:
Error: libgnome-keyring.so.0: cannot open shared object file: No such file or directory
at Error (native)
at process.module.(anonymous function) [as dlopen] (ELECTRON_ASAR.js:158:20)
at Object.Module._extensions..node (module.js:568:18)
at Object.module.(anonymous function) [as .node] (ELECTRON_ASAR.js:169:18)
at Module.load (module.js:456:32)
at tryModuleLoad (module.js:415:12)
at Function.Module._load (module.js:407:3)
at Module.require (module.js:466:17)
at require (internal/module.js:20:19)
at Object.<anonymous> (/opt/skypeforlinux/resources/app.asar/node_modules/keytar/lib/keytar.js:4:12)
That sucks. If this actually depends on gnome keyring, I'll just uninstall it.
(In reply to Jason A. Donenfeld from comment #63) > [...] > Error: libgnome-keyring.so.0: cannot open shared object file: No such file > or directory > [...] > (/opt/skypeforlinux/resources/app.asar/node_modules/keytar/lib/keytar.js:4: > 12) > > That sucks. If this actually depends on gnome keyring, I'll just uninstall > it. Sorry, I missed that one :( Fixed in -r1 (https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=911d96416a9fbde6e6324f1dfe9c7afa69d11304). And yes, it needs gnome-base/libgnome-keyring :) Under a PaX kernel, it's required to perform the steps described in the commented "use pax_kernel" section. Is it possible to uncomment it? Thanks (In reply to Wolfram Schlich from comment #62) > =net-im/skypeforlinux-1.8.0.2 is in Portage: > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=3b8777958b6d3d186986205015e5cdb7be81fb45 > :-) > > I'll now remove =net-im/skype-1.7.0.1:1. > > Thanks everyone! Guys, why did you call it skypeforlinux, not just skype as before? Did I miss something? Gentoo allows to install packages of different versions into different slots - why do we need two different packages with different names? (In reply to Pavel Kozlov from comment #66) > (In reply to Wolfram Schlich from comment #62) > > =net-im/skypeforlinux-1.8.0.2 is in Portage: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > > ?id=3b8777958b6d3d186986205015e5cdb7be81fb45 > > :-) > > > > I'll now remove =net-im/skype-1.7.0.1:1. > > > > Thanks everyone! > > Guys, why did you call it skypeforlinux, not just skype as before? Did I > miss something? Gentoo allows to install packages of different versions into > different slots - why do we need two different packages with different names? Upstream binary is called skypeforlinux, plus the two "versions" are so distinct architecturally that it makes more sense to have them named differently. Also, microsoft kinda fucked with version numbers and their "new" version registers as older than the classic one in portage's version number comparisons. Rather than put up with playing version number games it was decided that a new package name was a better idea. (In reply to Aldo Mazzeo from comment #65) > Under a PaX kernel, it's required to perform the steps described in the > commented "use pax_kernel" section. Is it possible to uncomment it? > > Thanks Aldo, please open up a new bug for that issue. Thank you! (In reply to Pavel Kozlov from comment #66) > (In reply to Wolfram Schlich from comment #62) > > =net-im/skypeforlinux-1.8.0.2 is in Portage: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > > ?id=3b8777958b6d3d186986205015e5cdb7be81fb45 > > :-) > > > > I'll now remove =net-im/skype-1.7.0.1:1. > > > > Thanks everyone! > > Guys, why did you call it skypeforlinux, not just skype as before? Did I > miss something? Gentoo allows to install packages of different versions into > different slots - why do we need two different packages with different names? There has been a discussion in this bug and a decision was taken. You're too late ;) (In reply to Wolfram Schlich from comment #69) > (In reply to Pavel Kozlov from comment #66) > > (In reply to Wolfram Schlich from comment #62) > > > =net-im/skypeforlinux-1.8.0.2 is in Portage: > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > > > ?id=3b8777958b6d3d186986205015e5cdb7be81fb45 > > > :-) > > > > > > I'll now remove =net-im/skype-1.7.0.1:1. > > > > > > Thanks everyone! > > > > Guys, why did you call it skypeforlinux, not just skype as before? Did I > > miss something? Gentoo allows to install packages of different versions into > > different slots - why do we need two different packages with different names? > > There has been a discussion in this bug and a decision was taken. > You're too late ;) Also, your suggestion for slots wouldn't have resolved the issue that prompted the new package name. We actually tried slots already. |
