Bug 483588 – Removal: app-arch/xarchiver (WAS: =app-arch/xarchiver-0.5.2-r3 with >=app-arch/unrar-5 - xarchiver sometimes shows file entries twice and with wrong values in several columns)

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description jospezial 2013-09-04 11:54:22 UTC]

+++ This bug was initially created as a clone of Bug #483380 +++

When I have unrar-4.2.4 installed, then ark and xarchiver work as expected with rar files.

When I have unrar-5.0.7 and or 5.0.8 installed, ark does not show the content (files). No error is shown. nothing found about in .xsession-errors.
Xarchiver shows the fileentries sometimes twice and with wrong values in the different columns.
It shows an error message an extracting.

jlgentoo ~ # emerge --info unrar
Portage 2.2.1 (default/linux/amd64/13.0, gcc-4.8.1, glibc-2.17, 3.11.0-rc7 x86_64)
=================================================================
                         System Settings
=================================================================
System uname: Linux-3.11.0-rc7-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_4400+-with-gentoo-2.2
KiB Mem:     4050296 total,   1766708 free
KiB Swap:    6012920 total,   6012920 free
Timestamp of tree: Mon, 02 Sep 2013 10:45:01 +0000
ld GNU ld (GNU Binutils) 2.23.2
ccache version 3.1.9 [enabled]
app-shells/bash:          4.2_p45
dev-java/java-config:     2.2.0
dev-lang/python:          2.7.5-r2, 3.2.5-r2, 3.3.2-r2
dev-util/ccache:          3.1.9
dev-util/cmake:           2.8.11.1
dev-util/pkgconfig:       0.28
sys-apps/baselayout:      2.2
sys-apps/openrc:          0.12
sys-apps/sandbox:         2.6-r1
sys-devel/autoconf:       2.13, 2.69
sys-devel/automake:       1.13.4, 1.14
sys-devel/binutils:       2.23.2
sys-devel/gcc:            4.8.1
sys-devel/gcc-config:     1.8
sys-devel/libtool:        2.4.2
sys-devel/make:           3.82-r4
sys-kernel/linux-headers: 3.10 (virtual/os-headers)
sys-libs/glibc:           2.17
Repositories: gentoo overlay_jl
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=native -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--autounmask-write=y --keep-going --quiet-build=y"
FCFLAGS="-march=native -O2 -pipe"
FEATURES="assume-digests binpkg-logs ccache config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-march=native -O2 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="de_DE.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.de.gentoo.org/gentoo-portage"
USE="3dnow 3dnowext 64bit X Xaw3d a52 aac aacplus aacs aalib ace acl acpi activefilter aften alsa amd64 ap apm apng archive async audacious audiofile automount avcodec bash-completion bazaar berkdb binary-drivers binfilter blender-game bluray boost bzip2 bzr cairo canusb ccache cdda cddb cdio cdparanoia cdr cdrdao cdrom cgi charconv chroot city cjk clang cleartype cli colordiff colors compress consolekit corefonts cpio cracklib crypt css cue cups curl curlwrappers cvs cxx daemon dbus declarative demo device-mapper dga dhcp doom doomsday dos dri dts dv dvb dvd dvdnav eap eap-sim eap-tls emerald emoticon enca encode enscript equalizer exif extensions extras faac faad fam farsight farstream fat fax fbcon fdformat ffmpeg fftw firefox flac floppy fluidsynth fontconfig foomaticdb fortran freedoom ftp fts3 fuse g3dvl gallium gbm gd gdbm gdu geoip gif gimp git glamor glib glut gme gnutls gphoto2 gpm graphite gsm gstreamer gtk gtk3 gudev gui gzip hddtemp hdf hdf5 heretic hexen highlight hwdb iconv icq icu id3 id3tag idn imagemagick introspection ios ipc ipod ipv6 irc jack java javascript jit jpeg jpeg2k kate kde keymap ladspa lame laptop lcms lensfun lha libass libcaca libcanberra libkms libnl libnotify libsamplerate libssh2 libtiger libv4l libv4l2 libwww live llvm lm_sensors logrotate lua lxde lzma lzo mad madwifi magic man matroska md5sum metalink midi mikmod mime minizip mixer mjpeg mmap mms mmx mmxext mng mod modplug modules mono mouse mozilla mp3 mp4 mpeg mplayer mtp mudflap multilib multislot musepack musicbrainz nano-syntax ncat ncurses ndiff network nfs nfsidmap nfsv3 nfsv4 nfsv41 nls nmap nmap-update nokia normalize nowlistening nping nptl nsplugin nss ntfs ntfsprogs ntp nvidia nvram obex ocr ogg ogm openal opencl opengl openmp optimized-qmake oscar osdmenu osmesa otr p2p pam pango panorama parport parse-clocks pcap pci pcre pdf pdfimport phonon pipes plasma plugins pm-utils pmu png policykit portaudio postscript ppds privacy projectm projectx pulseaudio pvr qalculate qt3support qt4 quicktime r600-llvm-compiler radio rar raw rdesktop readline recording redeyes reiser4 reiserfs remote-access remoteosd replaygain resources rpm rtc rtmp rtsp rubberband samba sbsms scanner schroedinger sdl secure-delete semantic-desktop sensord session sftp sha512 shorten shout skins slang smbclient smi sndfile snowberry sockets sound soundtouch speex spell sql sqlite sqlite3 sse sse2 sse3 ssh ssl startup-notification statistics stk stream subtitles subversion svg swat symlink syslog szip taglib tcpd texteffect tftp theora threads thumbnail tiff translator truetype twolame udev udisks unicode upcall upower urlpicpreview usb v4l vaapi vamp vcd vcdx vdpau video videos vidmode vim-syntax virtualbox vlm vnc vorbis vpx vroot vst wad wav wavpack webgl webkit webm webpresence wifi winbind winpopup wireshark wmf wps wxwidgets x264 xa xattr xcb xcomposite xfs xine xinerama xinetd xml xorg xosd xpm xrandr xscreensaver xv xvid xvmc zip zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="de" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2 python3_3" RUBY_TARGETS="ruby19 ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev vesa svga vga radeon v4l modesetting r600" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON

=================================================================
                        Package Settings
=================================================================

app-arch/unrar-4.2.4 was built with the following:
USE="(multilib)" ABI_X86="64"

not installed at the same time:

app-arch/unrar-5.0.8 was built with the following:
USE=""

[Comment 1 Tom Wijsman (TomWij) (RETIRED) 2013-09-05 09:54:56 UTC]

(In reply to jospezial from comment #0)
> It shows an error message an extracting.

Which error message?

[Comment 2 Samuli Suominen (RETIRED) 2013-09-06 13:48:57 UTC]

xarchiver has been abandoned for years now, so I'll vote for xarchiver removal:
http://git.xfce.org/archive/xarchiver/
(notice the archive/ category where everything unmaintained get ditched where no commits are expected)

it's even more dead than squeeze we already removed from tree:
http://git.xfce.org/apps/squeeze/
(notice it's not in archive/ but in apps/ which indicates it's still maintained)

it's true that Xfce doesn't have any own maintained archiver guis available, except those that from other desktops like 'ark' or 'file-roller' that can be used w/ thunar-archive-plugin

[Comment 3 Samuli Suominen (RETIRED) 2013-09-06 13:50:25 UTC]

also bug 473692 can be closed once it's gone

[Comment 4 Denis Lisov 2013-09-07 19:09:26 UTC]

Some development seems to be going on on Sourceforge
http://xarchiver.sourceforge.net/
with an SVN repo initialized in 2009 and the latest commit being just several days old
http://sourceforge.net/p/xarchiver/code/commit_browser

[Comment 5 Julian Ospald 2013-09-09 09:41:24 UTC]

Yes, the masking reasons are wrong altogether.

* mixing unstable and stable branch is unsupported, so saying it doesn't work with ~arch unrar is no reason to mask it
* it is NOT abandonded

I wonder how this even entered stable arch in the first place, because it has tons of bugs, but your masking reasons do not make sense.

[Comment 6 Samuli Suominen (RETIRED) 2013-09-09 09:58:19 UTC]

unrar-5 will go stable anyday now and I don't (as a maintainer) expect anyone to work on xarchiver, so getting rid of it seems fine to me
dropping it to ~arch is okay by me too, if you don't want it to leave the tree. then move it from xfce@ to maintainer-needed@ and reassing the bugs.
any future release are not likely to be XFCE related anymore, so we are not intrested anymore.

[Comment 7 Julian Ospald 2013-09-09 10:16:18 UTC]

Not interested is fine by me. Doesn't mean it has to be masked.

[Comment 8 Julian Ospald 2013-09-09 10:17:30 UTC]

+  09 Sep 2013; Julian Ospald <[e-mail]> package.mask:
+  revert mask wrt #483588

[Comment 9 Samuli Suominen (RETIRED) 2013-09-09 10:36:16 UTC]

so you are taking over and handling the unrar-5 issue? i mean, this will just get remasked as prereq of unrar-5 stabilization within days

[Comment 10 Pacho Ramos 2013-09-10 20:56:43 UTC]

And, what is the advantage of having this staying in maintainer-needed keeping it broken? We need fixes for this and bug 473692

[Comment 11 Pacho Ramos 2013-09-10 20:57:36 UTC]

And also you are referring to a "ton of bugs" that should be handled (if they are so major)

[Comment 12 Julian Ospald 2013-09-10 22:32:02 UTC]

(In reply to Pacho Ramos from comment #10)
> And, what is the advantage of having this staying in maintainer-needed
> keeping it broken? We need fixes for this and bug 473692

look at the upstream bug report at URL field

[Comment 13 Julian Ospald 2013-09-10 22:32:48 UTC]

(In reply to Pacho Ramos from comment #11)
> And also you are referring to a "ton of bugs" that should be handled (if
> they are so major)

From my personal experience with this software.

[Comment 14 Pacho Ramos 2013-09-10 23:11:59 UTC]

(In reply to Julian Ospald (hasufell) from comment #12)
> (In reply to Pacho Ramos from comment #10)
> > And, what is the advantage of having this staying in maintainer-needed
> > keeping it broken? We need fixes for this and bug 473692
> 
> look at the upstream bug report at URL field

The problem is how to deal with this and other bugs until upstream releases a new version including all the changes. Specially since this package doesn't have any maintainer downstream now. I would probably wait one or two months to see if upstream *really* makes a bump handling them, because, other times, I have also seen cases of people doing "rewrites" of old software that finally lead to no new version for a long time because they need a lot of time to rewrite all and, then, having a broken piece flying in the tree for months waiting for that. 

On the other hand, there are other cases with old software getting broken -> punted and, another new software (like "foo-reloaded" as an example) appearing some months after that and, then, following usual procedure of "New packages" to be added to the tree when they are really released and working ;)

[Comment 15 Julian Ospald 2013-09-10 23:18:57 UTC]

I cannot foresee the future, but this package works still on stable arch.

[Comment 16 Julian Ospald 2013-09-10 23:21:09 UTC]

also: I *might* take over maintainership in case the development of the new version goes well. Otherwise this is going to be masked or only dropped back to ~arch, because in the end this only affect RAR archives and nothing more. So the package is not severly broken.

[Comment 17 Markos Chandras (RETIRED) 2013-10-23 07:04:33 UTC]

(In reply to Julian Ospald (hasufell) from comment #16)
> also: I *might* take over maintainership in case the development of the new
> version goes well. Otherwise this is going to be masked or only dropped back
> to ~arch, because in the end this only affect RAR archives and nothing more.
> So the package is not severly broken.

The package is orphaned and it's semi-working. So it will be removed per treecleaner policy. Either take maintainership and fix it or stop messing with treecleaners bugs.

[Comment 18 Julian Ospald 2013-10-23 12:48:10 UTC]

(In reply to Markos Chandras from comment #17)
> (In reply to Julian Ospald (hasufell) from comment #16)
> > also: I *might* take over maintainership in case the development of the new
> > version goes well. Otherwise this is going to be masked or only dropped back
> > to ~arch, because in the end this only affect RAR archives and nothing more.
> > So the package is not severly broken.
> 
> The package is orphaned and it's semi-working. So it will be removed per
> treecleaner policy. Either take maintainership and fix it or stop messing
> with treecleaners bugs.

Maybe read the whole discussion in this bug, before making such comments. I was not messing with anything.

Treecleaners gave wrong reasons for masking, so I fixed it and I will do it again.

Bug 473692 however makes me agree with treecleaning.

[Comment 19 jospezial 2013-10-23 16:06:55 UTC]

I can live with kde-base/ark which was fixed in kde 4.11.2 for the new unrar.

But there is something happening:

http://sourceforge.net/p/xarchiver/code/HEAD/tree/trunk/

Hope the devolopers will fix the unrar bug.

[Comment 20 Julian Ospald 2013-10-23 16:13:07 UTC]

(In reply to jospezial from comment #19)
> I can live with kde-base/ark which was fixed in kde 4.11.2 for the new unrar.
> 
> But there is something happening:
> 
> http://sourceforge.net/p/xarchiver/code/HEAD/tree/trunk/
> 
> Hope the devolopers will fix the unrar bug.

He's kind of rewriting it, not just fixing bugs, so the ebuild might have to be rewritten from scratch anyway.

[Comment 21 Samuli Suominen (RETIRED) 2013-10-24 09:47:40 UTC]

xarchiver has *always* been broken in sense that it is incapable of opening multiple common formats, and pretty much any format with password protection
it has *always* crashed etc.
as new GTK+, GLib and others have been introduced, the incompability problems have also increased
as in, xarchiver has always been a poor quality software, same as Xfce's squeeze

i mean, what's the point of GUI archiver when you can't do all your archiving work with it and have to resort to commandline anyways?

so even if the mask message was wrong, it was wrong to remove the p.mask, since the Gentoo Xfce team (maintainer at the time) gave a go ahead for removing -- as in, the people who have maintained it from the day zero known the packages history, so i'm not very happy someone outside of the Xfce team then jumping in and saying it should be kept just because mask message is wrong and whatever

no need to reply, just venting a bit ;)

[Comment 22 Julian Ospald 2013-10-24 11:35:03 UTC]

Then I must have misunderstood you when you said

> dropping it to ~arch is okay by me too, if you don't want it to leave the tree.
> then move it from xfce@ to maintainer-needed@ and reassing the bugs.

[Comment 23 Markos Chandras (RETIRED) 2013-10-26 15:51:51 UTC]

(In reply to Julian Ospald (hasufell) from comment #18)
> (In reply to Markos Chandras from comment #17)
> > (In reply to Julian Ospald (hasufell) from comment #16)
> > > also: I *might* take over maintainership in case the development of the new
> > > version goes well. Otherwise this is going to be masked or only dropped back
> > > to ~arch, because in the end this only affect RAR archives and nothing more.
> > > So the package is not severly broken.
> > 
> > The package is orphaned and it's semi-working. So it will be removed per
> > treecleaner policy. Either take maintainership and fix it or stop messing
> > with treecleaners bugs.
> 
> Maybe read the whole discussion in this bug, before making such comments. I
> was not messing with anything.
> 
> Treecleaners gave wrong reasons for masking, so I fixed it and I will do it
> again.
> 
No you will not. If you want to keep it in the tree be responsible and take over maintainership. Otherwise stop causing us more troubles and let us do our job.

[Comment 24 Julian Ospald 2013-10-26 16:10:09 UTC]

(In reply to Markos Chandras from comment #23)
> (In reply to Julian Ospald (hasufell) from comment #18)
> > (In reply to Markos Chandras from comment #17)
> > > (In reply to Julian Ospald (hasufell) from comment #16)
> > > > also: I *might* take over maintainership in case the development of the new
> > > > version goes well. Otherwise this is going to be masked or only dropped back
> > > > to ~arch, because in the end this only affect RAR archives and nothing more.
> > > > So the package is not severly broken.
> > > 
> > > The package is orphaned and it's semi-working. So it will be removed per
> > > treecleaner policy. Either take maintainership and fix it or stop messing
> > > with treecleaners bugs.
> > 
> > Maybe read the whole discussion in this bug, before making such comments. I
> > was not messing with anything.
> > 
> > Treecleaners gave wrong reasons for masking, so I fixed it and I will do it
> > again.
> > 
> No you will not. If you want to keep it in the tree be responsible and take
> over maintainership. Otherwise stop causing us more troubles and let us do
> our job.

Since no one did proper research on the project status, the masking/treecleaning had to be reconsidered.

If you call that "causing trouble", then I am sorry.

As for the current situation:
After checking with upstream it seems there will not be any fixes backported, so existing bugs are unlikely to get fixed for the old versions. It is also not clear when the first alpha/beta versions will be released.

Since treecleaners seem to go for quick decisions sometimes like in bug 394869 I will keep "causing trouble" (aka helping).

[Comment 25 Pacho Ramos 2013-10-26 16:22:45 UTC]

(In reply to Julian Ospald (hasufell) from comment #24)
[...]
> Since no one did proper research on the project status, the
> masking/treecleaning had to be reconsidered.

That doesn't look to be true seeing the comments from Samuli about the status of the project and how it's still broken now (since new upstream still didn't release any new version with the fixes)

> 
> If you call that "causing trouble", then I am sorry.
> 
> As for the current situation:
> After checking with upstream it seems there will not be any fixes
> backported, so existing bugs are unlikely to get fixed for the old versions.
> It is also not clear when the first alpha/beta versions will be released.
> 
> Since treecleaners seem to go for quick decisions sometimes like in bug
> 394869 I will keep "causing trouble" (aka helping).

"Quick"?? Did you review the history of that bug report? Since the problem was reported (and confirmed by some people and developers) 10 months passed until the mask, and its maintainer didn't put any comment (even if I put a comment announcing that I was going to mask it before to let him know). Of course that bug is still opened as usual (even the original bug 392869 is still there completely unattended)

[Comment 26 Julian Ospald 2013-10-26 16:30:50 UTC]

(In reply to Pacho Ramos from comment #25)
> (In reply to Julian Ospald (hasufell) from comment #24)
> [...]
> > Since no one did proper research on the project status, the
> > masking/treecleaning had to be reconsidered.
> 
> That doesn't look to be true seeing the comments from Samuli about the
> status of the project and how it's still broken now (since new upstream
> still didn't release any new version with the fixes)
> 

I looked over all comments and the first one realizing it is not abandoned is the user in #c4

> > 
> > If you call that "causing trouble", then I am sorry.
> > 
> > As for the current situation:
> > After checking with upstream it seems there will not be any fixes
> > backported, so existing bugs are unlikely to get fixed for the old versions.
> > It is also not clear when the first alpha/beta versions will be released.
> > 
> > Since treecleaners seem to go for quick decisions sometimes like in bug
> > 394869 I will keep "causing trouble" (aka helping).
> 
> "Quick"?? Did you review the history of that bug report? Since the problem
> was reported (and confirmed by some people and developers) 10 months passed
> until the mask, and its maintainer didn't put any comment (even if I put a
> comment announcing that I was going to mask it before to let him know). Of
> course that bug is still opened as usual (even the original bug 392869 is
> still there completely unattended)

That decision is still wrong. Packages that work for some and not for others are not candidates for removal. Those are just valid bugs and a reason a package should not be stabilized.

[Comment 27 Markos Chandras (RETIRED) 2013-10-26 16:38:21 UTC]

(In reply to Julian Ospald (hasufell) from comment #24)
> (In reply to Markos Chandras from comment #23)
> > (In reply to Julian Ospald (hasufell) from comment #18)
> > > (In reply to Markos Chandras from comment #17)
> > > > (In reply to Julian Ospald (hasufell) from comment #16)
> > > > > also: I *might* take over maintainership in case the development of the new
> > > > > version goes well. Otherwise this is going to be masked or only dropped back
> > > > > to ~arch, because in the end this only affect RAR archives and nothing more.
> > > > > So the package is not severly broken.
> > > > 
> > > > The package is orphaned and it's semi-working. So it will be removed per
> > > > treecleaner policy. Either take maintainership and fix it or stop messing
> > > > with treecleaners bugs.
> > > 
> > > Maybe read the whole discussion in this bug, before making such comments. I
> > > was not messing with anything.
> > > 
> > > Treecleaners gave wrong reasons for masking, so I fixed it and I will do it
> > > again.
> > > 
> > No you will not. If you want to keep it in the tree be responsible and take
> > over maintainership. Otherwise stop causing us more troubles and let us do
> > our job.
> 
> Since no one did proper research on the project status, the
> masking/treecleaning had to be reconsidered.
> 
> If you call that "causing trouble", then I am sorry.
> 
> As for the current situation:
> After checking with upstream it seems there will not be any fixes
> backported, so existing bugs are unlikely to get fixed for the old versions.
> It is also not clear when the first alpha/beta versions will be released.
> 
> Since treecleaners seem to go for quick decisions sometimes like in bug
> 394869 I will keep "causing trouble" (aka helping).

As you wish then

[Comment 28 Pacho Ramos 2013-10-26 16:39:49 UTC]

(In reply to Julian Ospald (hasufell) from comment #26)
[...]
> That decision is still wrong. Packages that work for some and not for others
> are not candidates for removal. Those are just valid bugs and a reason a
> package should not be stabilized.

Yeah, I agree it was an *error*, but I wanted to try to explain you why it was an error instead of a "general procedure" like your previous comment suggest. It's not so easy to try to handle all kind of broken packages that are spread on the tree, as they are completely different. It was an error and I think it's normal, like in this bug report you were too optimistic thinking the package could be kept a bit more since it had a new upstream... but it was also an error (and I also think it's normal too) since, sometimes, having a new upstream isn't enough because in some cases the decide to mess up a lot with the package, delaying the fixes for months (if they are fixed ever)

Wouldn't be much better to try to help, for example, fixing bugs assigned to maintainer-needed? I think that your man power could be much more useful there. You can look at most important bugs:
http://tinyurl.com/p5gt33j

this is the bug search I apply when I have time to fix some bugs in maintainer-needed packages

[Comment 29 Markos Chandras (RETIRED) 2013-10-26 16:50:14 UTC]

(In reply to Pacho Ramos from comment #28)
There is no point to discuss this more. Since he does not want to take over maintainership (for whatever reason) of the package the treecleaners will proceed with the removal as planed because this has always been the case with m-n semi-broken packages.

[Comment 30 Julian Ospald 2013-10-26 16:59:47 UTC]

(In reply to Markos Chandras from comment #29)
> (In reply to Pacho Ramos from comment #28)
> There is no point to discuss this more. Since he does not want to take over
> maintainership (for whatever reason) of the package the treecleaners will
> proceed with the removal as planed because this has always been the case
> with m-n semi-broken packages.

I explained it in this bug report, too. I am following upstream development and if there is any alpha/beta version I'd be happy to maintain it. But since the rewrite is a fundamental rewrite, it doesn't help us with maintaining the old versions.

Another option is still to just drop it back to "~arch" since these are only 2 formats not working, but I won't argue about that and I am not blocking any actions here. I removed the mask _after_ discussing the reasons and the maintainer said:

> dropping it to ~arch is okay by me too, if you don't want it to leave the
> tree.then move it from xfce@ to maintainer-needed@ and reassing the bugs.

so I have no idea why you are so hostile.

[Comment 31 Markos Chandras (RETIRED) 2013-10-26 17:05:25 UTC]

(In reply to Julian Ospald (hasufell) from comment #30)
> (In reply to Markos Chandras from comment #29)
> > (In reply to Pacho Ramos from comment #28)
> > There is no point to discuss this more. Since he does not want to take over
> > maintainership (for whatever reason) of the package the treecleaners will
> > proceed with the removal as planed because this has always been the case
> > with m-n semi-broken packages.
> 
> I explained it in this bug report, too. I am following upstream development
> and if there is any alpha/beta version I'd be happy to maintain it. But
> since the rewrite is a fundamental rewrite, it doesn't help us with
> maintaining the old versions.
> 
> Another option is still to just drop it back to "~arch" since these are only
> 2 formats not working, but I won't argue about that and I am not blocking
> any actions here. I removed the mask _after_ discussing the reasons and the
> maintainer said:
> 
> > dropping it to ~arch is okay by me too, if you don't want it to leave the
> > tree.then move it from xfce@ to maintainer-needed@ and reassing the bugs.
> 
The package is broken *as it is right now*. You don't want to maintain it *now* so we will remove it. If there is ever going to be a proper release, then bring it back. Simple as that. This is *exactly* the same thing with what we did with lightdm. it was broken and abandoned for years, we removed it, and when upstream became active again, we brought it back.

The maintainer said what he said, but m-n bugs are treecleaners' job to be cleaned up.

[Comment 32 Julian Ospald 2013-10-26 17:09:19 UTC]

(In reply to Markos Chandras from comment #31)
> The maintainer said what he said, but m-n bugs are treecleaners' job to be
> cleaned up.

Well, I cannot rule out if it was a misunderstanding in some way (he didn't respond to that question).

But last time I checked the maintainer was member of the treecleaners project.

[Comment 33 Markos Chandras (RETIRED) 2013-10-27 12:24:07 UTC]

(In reply to Julian Ospald (hasufell) from comment #32)
> (In reply to Markos Chandras from comment #31)
> > The maintainer said what he said, but m-n bugs are treecleaners' job to be
> > cleaned up.
> 
> Well, I cannot rule out if it was a misunderstanding in some way (he didn't
> respond to that question).
> 
> But last time I checked the maintainer was member of the treecleaners
> project.

This is not relevant. He or any other treecleaner can take care of that. I believe Samuli talked from the xfce perspective. It does not mean was was talking on behalf of treecleaners at the same time. xarchiver in its current form/code has been abandoned. So it has to be removed (again, like we did with lightdm) and if/when it becomes usable again, feel free to introduce it to the tree again. Again, this is *standard* policy for semi-broken *maintainer-needed* packages so given you are not taking maintainership of this package, this is our responsibility to handle it.

[Comment 34 Markos Chandras (RETIRED) 2013-12-02 19:54:20 UTC]

Gone

[Comment 35 Samuli Suominen (RETIRED) 2014-05-11 17:48:47 UTC]

I'm adding xarchiver-0.5.3 to Portage now. It has these issues fixed, .xz support, rar5 support, etc

[Comment 36 Julian Ospald 2014-05-12 20:49:09 UTC]

(In reply to Samuli Suominen from comment #35)
> I'm adding xarchiver-0.5.3 to Portage now. It has these issues fixed, .xz
> support, rar5 support, etc

is that the rewrite already?