Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#4007 closed Bug (fixed)

daemon stops updating tracker with upload/download messages

Reported by: Astara Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.20
Severity: Normal Keywords: tracker hang; traffic stops;
Cc:

Description (last modified by jordan)

(Previously: #3829, #3997)

Won't presume to know why ... I just noticed using 'TR_CURL_VERBOSE', and then wireshark, that no traffic was going to the tracker to send it updates. Clients were talking but only had 1 tracker for all the torrents I currently have and after I had let it run for a while, I noticed that the CURL_VERBOSE log file had stopped growing -- that's when I checked in wireshark -- no traffic going to the tracker.

Could be related to some previous errors I filed, but without seeing the TCP-port reused messages in wireshark, can't really say it is the same...

Attachments (9)

output.log-201102091422.bz2 (114.8 KB) - added by Astara 11 years ago.
stdout+err output log from transmission w/CURL VERBOSE
filtered.log.lz (117.3 KB) - added by Astara 11 years ago.
block1.bin.lz (204.7 KB) - added by Astara 11 years ago.
block2.bin.lz (192.2 KB) - added by Astara 11 years ago.
filtered.lzma (101.4 KB) - added by Astara 11 years ago.
filtered2.log.lzma (46.7 KB) - added by Astara 11 years ago.
filtered4.log.lzma (71.3 KB) - added by Astara 11 years ago.
longer (10 min) logfile
ish-baka-bad-cnv-xmit....png (184.0 KB) - added by Astara 11 years ago.
short converation from wireshark showing 1 type of prob
versions (19.5 KB) - added by Astara 11 years ago.
versions of all files in 'work' build…

Download all attachments as: .zip

Change History (45)

Changed 11 years ago by Astara

stdout+err output log from transmission w/CURL VERBOSE

comment:1 Changed 11 years ago by jordan

Hm. if the curl file stops growing altogether, let's record the announcer.c log messages too so that we can see if announcer is trying to feed urls to libcurl or not. Try this ball of joy (all one line, of course):

TR_CURL_VERBOSE=1 TR_DEBUG_FD=2 transmission-daemon -f 2>&1 | grep --line-buffered -e "^ " -e "^<" -e "^>" -e "^\*" -e announcer\.c > runlog

comment:2 Changed 11 years ago by jordan

  • Summary changed from transmission-d stops updating tracker with upload/download messages to daemon stops updating tracker with upload/download messages

comment:3 follow-up: Changed 11 years ago by Astara

How come you don't just log it all to a file and then run grep on the result?

Also wouldn't it be easier to use pcregrep (or egrep usually slower) and 1 pattern: "( |<|>|\*)|announcer\.c". Also , wondering, why you think you need the --line-buffered arg, since it seems the only thing it is good for is causing a slow at you are trying to do with the '--line-buffered' arg.

Anyway...will get to it before too long...have a bunch of other things clamoring for my attention...

comment:4 in reply to: ↑ 3 ; follow-up: Changed 11 years ago by jordan

  • Severity changed from Major to Normal

Replying to Astara:

How come you don't just log it all to a file and then run grep on the result?

Also wouldn't it be easier to use pcregrep (or egrep usually slower) and 1 pattern: "( |<|>|\*)|announcer\.c". Also , wondering, why you think you need the --line-buffered arg, since it seems the only thing it is good for is causing a slow at you are trying to do with the '--line-buffered' arg.

I'm not sure why you bothered critiquing the grep syntax instead of just providing the log.

Use what you like, as long as it works. The time spent typing in comment:3 was more than the time the CPU will use on any of these approaches.

Anyway...will get to it before too long...have a bunch of other things clamoring for my attention...

Changing priority to "normal," then.

comment:5 in reply to: ↑ 4 Changed 11 years ago by Astara

Replying to jordan:

I'm not sure why you bothered critiquing the grep syntax instead of just providing the log.

Well I was trying to find out if there was a particular reason for doing it that way, not so much to critique it.

Changing priority to "normal," then.

Um...ok, I could agree to that, but that's not what you did...;-) You changed the severity and not the priority... oops.

comment:6 Changed 11 years ago by jordan

  • Priority changed from High to Normal

whee!

Changed 11 years ago by Astara

comment:7 Changed 11 years ago by jordan

Whatever you did, it didn't include the announcer.c output.

$ lzcat filtered.log.lz | grep announcer.c | wc -l
0
$ TR_CURL_VERBOSE=1 TR_DEBUG_FD=2 transmission-daemon -f 2>&1 | grep --line-buffered -e "^ " -e "^<" -e "^>" -e "^\*" -e announcer\.c > runlog
(waits a minute or two; hits ctrl-c)
$ grep announcer.c runlog | wc -l
13

comment:8 Changed 11 years ago by Astara

Hmmm....

Something's strange:

>grep -c 'announce\.c' output.log
0
Ishtar:transmission/logs> grep -c 'announce.c' output.log 
0
Ishtar:transmission/logs> grep -c 'announce' output.log  
12482
Ishtar:transmission/logs> 

That's because the string 'announce\.c' isn't in the raw output. 'announce' is... ... looking in the environment (/proc/<pid>/environ...I see TR_DEBUG_FD=...hmmm... not what I expect. It's set, but not to any value... ARG...I created the file in the transmission/etc/ directory (debug_fd) but didn't put a value in the file, so of course it got set to null! GRRR)

# echo 2 >~transmission/environ/TR_DEBUG_FD

Ah, I think I know what happened -- I forgot the space after the '2'. So picky these shells. Ooops!

I have to go out for a few hours for an appointment, I'll start it off before I leave and get it to you when I get back...

Changed 11 years ago by Astara

Changed 11 years ago by Astara

comment:9 Changed 11 years ago by Astara

Have to concatenate the files together after expansion to get the full filtered logfile.

My Gawd! The raw was 127G long, filtered 27M, removed pathnames & proper names ->15M that's what I ended up with ...

comment:10 Changed 11 years ago by jordan

Most of the TR_CURL_VERBOSE is missing this time.

Here's the log generated for comment:7 using the clumsy-but-works procedure in comment:1:

$ grep -C 5 event= runlog
[21:41:44.091] [ubuntu-10.10-desktop-i386.iso--torrent.ubuntu.com:6969] appended event "started"; announcing in 0 seconds (announcer.c:780)
[21:41:44.878] [ubuntu-10.10-desktop-i386.iso--torrent.ubuntu.com:6969] announcing tier 0 of 1 (announcer.c:1504)
* Expire cleared
* About to connect() to torrent.ubuntu.com port 6969 (#0)
*   Trying 91.189.90.143... [21:41:46.004] 86.62.98.228:19901 libevent says this peer is ready to read (peer-io.c:227)
> GET /announce?info_hash=%bc%f2%e5%87%af%d4%d3%b1%bd%d8%ec%e5%15%0d%9f%b4%d2%95%8a%f4&peer_id=-TR2130-jkae4je6m20e&port=51413&uploaded=0&downloaded=0&left=0&numwant=80&key=71wcs1qa&compact=1&supportcrypto=1&requirecrypto=1&event=started HTTP/1.1
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Content-Length: 411
< Content-Type: text/plain
< Pragma: no-cache

And here's the log in comment:9

$ lzcat block*bin.lz | wc -l
155863
$ lzcat block*bin.lz | grep -C 5 event=
$ lzcat block*bin.lz | grep event= | wc -l
0

Changed 11 years ago by Astara

comment:11 Changed 11 years ago by Astara

??? Are you insinuatin' things again!?! ;-)

I was pretty sure I checked the environ before letting it run (i.e. looking @ /proc/<pid> of the transmission process and verifying that the 'environ' had the TR_CURL_VERBOSE=1 and TR_DEBUG_FD=2;

oh...I see...it was my trying to delete the literals that caught those (well it shorted it by another 25%, hmmm....maybe you don't need the whole 2-3 hours of log to track this down, eh? running the grep on the output log again (I hadn't deleted the output -- benefit of redirecting it to a file)...

you may be interested in knowing your grep line runs twice as fast as the one I suggested with pcregrep! Always good to check one's assumptions about efficiency... grep is real good with static strings, it gets slower on many regular expressions that pcregrep, but this isn't an RE...oh well...

ok...maybe 3rd time's a charm?

comment:12 Changed 11 years ago by jordan

The line numbers in filtered.lzma indicate that it was generated by Transmission 2.12 or 2.13, which predates all the changes made for #3931, #3933, #3934, #3870, and #3836.

Would it be possible to get a log from 2.20 or 2.21?

comment:13 Changed 11 years ago by Astara

Will have to pull down a new tree, so it will be a bit longer turnaround....not to mention getting a hard disk error on one of my PC's..w/a guest over who wants to use it...sigh...

comment:14 Changed 11 years ago by jordan

  • Description modified (diff)

comment:15 Changed 11 years ago by Astara

Got a problem -- not sure if I should file a bug on it or not, or what'cha want, but pulled the latest source and I'm having problems getting it to build on SuSE 11.2(x64). It's stumbling over 'libevent'. Looks like the highest I have even in 11.3 is 1.4.12, and 11.4 which isn't due out for another month or so is at libevent 1.4.14-something.

Looks like you like you need libevent 2 something to build transmission now?

Um.... gonna be a bit hard to try those changes at this point... --- update... found source trying to make/config...

I remember having problems with libevent last time when I made 2.12, but I got around them and was using libevent 1.4.x or similar...but not even sure where to pull a libevent make package, let along one that builds on suse, at this point...

;-(

Last edited 11 years ago by Astara (previous) (diff)

Changed 11 years ago by Astara

comment:16 Changed 11 years ago by Astara

I don't know how useful this will be (attached 'filtered2.log.lzma). The newly compiled version doesn't run very long before it exits with no message indicating why it exits.

I don't suppose you've thought about trapping trappable errors and trying to give some sort of info state before crashing? There's not even any core file, which seems odd...

It did run for *almost* 10 minutes before dying...and produced a 3 Gig logfile! *cough*. the last bit in the logfile was:

 [10:03:56.200] web adding task to curl: [http://tracker.openbittorrent.com/scrape?info_hash=%e5%c9%3f%23%d3%86%fe%00k%20~%f6%60%2a%cb%12%9ce%f5%3d] (web.c:322)
* About to connect() to tracker.openbittorrent.com port 80 (#0)
*   Trying 95.215.62.5... 
-> -> output stopped here-^

Output stopped mid-line, where indicated.

Last edited 11 years ago by Astara (previous) (diff)

comment:17 Changed 11 years ago by jordan

Odd, your log only seems to run for about a minute, ending at 09:55:10, while your quote in comment:16 lists something form 10:03:56.

Oh well, I guess it doesn't matter if transmission is exiting on you. That's the first report I've heard of that, which makes me wonder if it's a local build issue. Maybe you can tease some information out of transmission wrt where it's exiting from...

Changed 11 years ago by Astara

longer (10 min) logfile

comment:18 Changed 11 years ago by jordan

...but the announces in this log are successful! What are you wanting me to look at in filtered4.log?? :)

comment:19 follow-up: Changed 11 years ago by Astara

Twas the rest of filtered2.log -- didn't know it had been chopped off, but it wasn't long enough to duplicate the problem anyway.

No idea why it dies so quickly at this point. Going to have to setup a test environment, since this is way to unstable to be used on this many torrents right now.

comment:20 in reply to: ↑ 19 Changed 11 years ago by jordan

Replying to Astara:

Twas the rest of filtered2.log -- didn't know it had been chopped off, but it wasn't long enough to duplicate the problem anyway.

Fair enough. Thanks.

No idea why it dies so quickly at this point. Going to have to setup a test environment, since this is way to unstable to be used on this many torrents right now.

Okay. Keep me posted if you're able to generate a log that demonstrates the behavior. :)

comment:21 Changed 11 years ago by jordan

Any news?

comment:22 Changed 11 years ago by jordan

Any news?

comment:23 Changed 11 years ago by Astara

Only news is that all of the original problems are back along with a new problem of an occasional crash (under the version I'd been using for months w/no crashes -- i.e. same binary) -- thought that hasn't happened after I reduced the number of active torrents.

It seems that that could be a possible 'third stage' of the bug that I'd never reached before.

Before, when I'd gotten to around ~450 seeders on 1 tracker, I ran into the problem of losing upload/download info on that tracker. So I backed off from the 450 back down to about 150 , which allowed some occasional progress before it would stop talking to the tracker.

But in my recent ramping up and restoring of all the torrents I'd lost, I had almost 650 torrents to 1 tracker and had a few crashes (no core, no log messages, just no longer running) after 6-18 hours. If I activated DEBUG messages, the crashes would happen within the first hour (usually first few-to-several minutes) of running -- again, no core, no log messages, just no longer running.

Trying to upgrade to a newer(latest pulled source) version resulted in something that would either not compile or that would 'exit' almost immediately after starting -- AND on nearly every (maybe every?) attempt, wiped all of the verification data in the resume or torrent files (whichever they were stored in), such that even going back to an earlier version wouldn't help.

I had a similar problem with the older (2.12+?) version I was using crashed -- in that every torrent that was 'downloading' would go into a state of needing to be re-verified. On top of that, some minority percentage of 'complete' torrents would also be marked as needing verification, so when I had as many as 150 torrents in a state of being downloaded & some additional number

Dakara, due to the design flaw (not a bug, as this unwanted (by users) behavior is 'by design'), of transmission having no way for the user to set or reset a torrent's verification state to verified (or 'verified' for the 'xx%' that had been previously marked as being successfully the downloaded (implying 'verified')), a verification of hundreds of torrents would start each time I tried to look at the problem (as I had quite a few torents downloading at the time).

This put me off the 'test cycle' at that time, since I have disabled any 'on demand' verification, as it creates a sluggish machine for the next few days as transmission is spontaneously going off and verifying sections at random, making transmission, -- already one of the largest hogs of cpu resources on the system, even worse.

Side note: this 'on demand' behavior for verification is nearly guaranteeing lower performance for transmission in serving data for any torrent, since it guarantees that at least one remote client (the one requesting the data) will be kept waiting while the block is verified, for EACH block in the torrent, whereas verification 'en masse' at the beginning, will create an initial block for downloading, once that initial period has passed, there will be no more waits. In the worst case, you have remote clients waiting on data for each the torrents needing verification that will have to 'wait', once, before things get started. But in the best case, there would be no clients waiting on the torrents

needing verification, and the demand for those torrents won't come until sometime later when all the torrents have been verified. In that case, no clients will be kept waiting.

But in 'on-demand', EVERY block of a torrent will generate a 'wait' condition for some client while that block is verified. This is guaranteeing the worst performance each time while giving the user the false impression that there is 'no delay' because they see things moving from the start. Hiding worse performance behind a facade of inefficient action is not only deceptive to the user, but a huge waste of resources to have invested so much programming time in a feature that is only designed to make the user 'feel good' at the expense of real performance.

That said, however, perception has long been given more importance in the marketplace than actual performance, so this design decision is consistent with industry 'best [​sic] practices' (which in many cases, are not in the best interest of the user).

Anyway, due to the large performance and stability problems created testing this scenario I'm waiting until my torrent situation becomes more stable and/or I can setup a more isolated test environment before working on this, since due to transmission's design, testing and fixing problems -- especially when 'resume' files are messed up are horribly resource intensive and costly.

Right now I'm experiencing all the 'wonderful' symptoms of the bug, most obviously on the most heavily used tracker, such as 1) where newly added torrents stay in the 0/0 seeders/peers state until I restart transmission, 2) there is no accounting of traffic I download or upload, 3) every few days I'll see on my 'site page' that I have 0 active torrents even though my local client lists over 400 (I just 're-activated my 'cron-job' that checks for this 4 times/hour and restarts transmission when it detects that the tracker site isn't registering any activity), and 4) when looking through the tracker(s) lists for torrents -- it gets to a point where ALL torrents to all trackers sites eventually show 'updating', and they just stay stuck in that state -- never finishing an update request.

Sidenote FWIW, when it comes to supporting users or distros in making transmission, I believe bash (among others) provided a good example in it's reliance on the readline library. Since bash was often using the leading edge of readline in its releases, it included (and still does) the source to build the version of readline that it needed, in case your distro didn't have the necessary version. NOW, most distros have the version of readline that bash needs and when doing a 'configure', you can select whether to use an installed version of readline or to build and use the version included with bash. The default, now, I believe is to try to use the native, but if it isn't detectable or the version isn't high enough, then it uses the included version.

It would really be a benefit to users to include lib sources for the cutting edge versions of libraries like libevent2 since most distros don't have it. Even Fedora15 which was cited as having the necessary library, isn't due for an official release until May 1st (presuming it hasn't or won't slip again). This not only makes it difficult for end users to build your product, as it's guaranteed, you are using libs that won't be on their system.

It will also make it difficult for distro manufacturers to include the latest versions of your product if your product requires a version of a library that is too far out in front of other apps that use that library. I.e. it doesn't appear that libevent2 is a drop-in, backwards compatible replacement for libevent 1.x. If that's the case then distro-compilers will have to chose to drop apps that are still using 1.x OR they'll just wait another cycle or two until most of the products it bundles are using the same level -- OR, if a large number of apps use the libs and their is a split, then they'll usually release both libs in the same release -- but whatever they do, it complicates their life if your desire is for them to use your latest and greatest...

Anyway -- just another 2 cents about that 'lib thing'....meanwhile...it's something I'll eventually get around to, I'm sure, as I continue to get obstacles to my being able to further investigate this issue -- since I still use the product and since it's still a problem, its going to be something I'm going to have to get to sooner or later, but I'm not even unpacked (and still can't find things) from a carpet-damage-related 'move' so it may take a while...*sigh*

comment:24 Changed 11 years ago by jordan

Does that mean no news in getting a log from a 2.2x build?

comment:25 Changed 11 years ago by Astara

Um...that was the news... ;/

Problems building, problem where turning on logging increases probability of crashing.

All original symptoms back + new ones....(like crashing under even higher loads), and all sites indicating 'updating'...

I've made suggestions in more than one area to make transmission easier to debug and more reliable, but you don't seem interested. I've made suggestions about making it easier to build, but you don't seem interested. I gave you a log format but then you didn't like the version I included for the log file (which may or may not correspond to the version on the source code), but I'm guessing is from source code that was from last October. If that corresponds to 2.12+ than that is a correct version number, but I can't guarantee that version numbers you see in submitted log file(s) will always correspond to the corresponding version of the source code.

As I have, at least, hinted, if not said, before, I have to 1) stick with non-test version numbers and 2) have to be careful about using 'bleeding edge' version numbers that may not be on tracker white lists yet...

The client behaves differently depending on how it is compiled and will take different code paths -- I've already observed different execution behavior based on whether or not logging is turned on or off. It may be that by turning on logging, it hides the bug due to time issues.

As an example, with one specific problem I had in another product, they asked for the exact options and flags I used with configure so they could try to generate the same thing I was using. In at least one case it uncovered some problems in their configure script. In that case, as soon as those problems were fixed, my problems went away.


In order to move ahead with this, would you provide a version of your source that compiles on some recent version of 'SuSE' -- as it is in the "top 3 use distro's"...(http://distrowatch.com/dwres.php?resource=major)

Having the released version of transmission be able to build (and run) on the released version of the top 5 (or more) distro's would seem to be a reasonable request, in general, but I'm just asking for a version that will compile on Suse 11.3 or Suse 11.2 (or Suse 11.4 through it technically isn't out for a few more days...)....

Then I can get you your log file...

comment:26 Changed 11 years ago by jordan

About the "Astara suggested X, but Jordan's not interested; Astara suggested Y, but Jordan's not interested" ... that's irrelevant to the topic in this ticket.

What would move this ticket forward is a log from a recent trunk build of Transmission which shows the behavior you're reporting. I don't see how the rest of these topics such as lazy-verify are productive for this ticket.

Upgrading Transmission to libevent 2 was a lot of work. The idea of undoing it so that 2.2x will build on a version of SuSE that's sticking with Transmission 2.1x anyway is madness.

comment:27 Changed 11 years ago by Astara

I didn't say 'how' to provide a version that will compile on a released version of Suse 11.x.

You could make use of the open suse build service (open to anyone, for free) "https://build.opensuse.org/" to build a version of transmission 2.2 that will build on Suse 11.x. That may include following in the footsteps of such projects like 'bash' and including the necessary versions of libraries that are ahead of the distro with your tarbar, that are used in the even that the distro you are building on doesn't have a version that is up to the level you require.

I am not sure, but I believe I've heard rumors that some of the build machines have other distro's loaded to allow multi-distro testing to ensure a tarbal or source-rpm will build on the top distro's...but I'm not sure how that works. At the very least it would give an opportunity for increased exposure and testing as well as almost guaranteed acceptance or your latest versions by those distros for whom your stuff just simple works on...

Changed 11 years ago by Astara

short converation from wireshark showing 1 type of prob

comment:28 Changed 11 years ago by Astara

I really wish I could give you more what you want, but I can't at this point.

All I can do is run standard diagnostics that are known to work that indicate types of problems that are occurring. I'm not trying to be difficult -- if I could give you the log you wanted, I certainly would. I want this solved as much as anyone, so please don't think I'm not giving you want you want just to be difficult. It's because what you are asking is difficult to create on my system.

FWIW...I ran some more wireshark traces...and looking at the conversation on 1 port, (see attached picture), it appears that the tracker is closing the connection on my client before the client can even send any data -- perhaps indicating an 'overload' condition on the tracker (I noted about 780 TCP connections between my client and the tracker in the first 10 minutes of activity).

Despite the tracker closing the connection, the client went on to try to send data ANYWAY -- to which the tracker then responded with 'RST'(reset) messages.

I.e. it appears a 'close message' is coming back from the tracker, AFTER a connection has been opened, but before any data has been sent -- then the transmission client goes ahead and tries to send data anyway rather than restarting the connection attempt from scratch.

So this appears to be a case where the connection itself doesn't fail, but is closed immediately before any data is allowed to be sent from transmission - possibly with the 'close' and the data-transmission messages criss-crossing in transit.

Will attach a png of the *short* conversation....

comment:29 Changed 11 years ago by jordan

What svn revision of Transmission is that screenshot from?

Changed 11 years ago by Astara

versions of all files in 'work' build...

comment:30 Changed 11 years ago by Astara

Since each of the files as a version number on them, I included those as my answer in an attached file.

Note that the current version in 'work' doesn't build due my having 'messed' up my 'libevent' lib that this 'work' version linked with. So I'm not quite sure what I did but I can't even generate the working binary I'm using right now which is extremely frustrating, which has led me to think I need to get a separate build and root-dir test setup apart from my normal production environment -- setting that up has proved to be WAY more work than I anticipated, thus stopping any forward progress in working on this for now... until I figure out how to go about doing what I need to do. It doesn't help that my focus/concentration has been extra off the last few months due to alot of physical stress necessitating much larger than normal quantities of meds that mess up my ability to think -- driving me to insanity, besides making me increasingly depressed mentally messed up (which, BTW, partly is a reason for my sometimes (often?) annoying behavior (not to say that I've ever been noted as 'really easy to get along with', but ....) .... (none of which I consider something that you should even have to be aware of, let along make any allowance for; it just 'is').

comment:32 Changed 11 years ago by jordan

"transmission-daemon --version" is a simpler way of getting the svn revision number... but okay.

The version that screenshot came from has a five month old version of announcer.c that's missing all the changes made in related tickets that I described earlier in comment:12. What's the point?

comment:33 Changed 11 years ago by Astara

comment28:

I really wish I could give you more what you want, but I can't at this point.

comment26:

I didn't say 'how' to provide a version that will compile on a released version of Suse 11.x.

You could make use of the open suse build service (open to anyone, for free) " https://build.opensuse.org/" to build a version of transmission 2.2 that will build on Suse 11.x. That may include following in the footsteps of such projects like 'bash' and including the necessary versions of libraries that are ahead of the distro with your tarbar, that are used in the even that the distro you are building on doesn't have a version that is up to the level you require.

If you don't want to include the source, you could download the latest source 'dynamically', if you trust their latest to always build. Otherwise, you could include the version you used to build your version, since it's always possible that between the time you release your version and the time someone builds transmission, someone updates 'evlib' to a version that has some incompatibility with the one that you used -- including the exact sources you need to build your product that are NOT in current distributions (top 3? top 5? top 10?) is a way of ensuring that people can build your product even if their distributions versions of libraries aren't up at the level you are using for development or if an external source of those libs gets out-of-sync with the version you used for development.

comment25:

In order to move ahead with this, would you provide a version of your source that compiles on some recent version of 'SuSE' -- as it is in the "top 3 use distro's"...( http://distrowatch.com/dwres.php?resource=major)

I'm including, perhaps unhelpful, data from the only version I have working right now. If you want to help me move forward (I would appreciate it!), then having a version I can compile on my machine would be a way to move things forward. Otherwise, it's going to take a while...

It just took me 4 days to write a shell script that should have taken a few hours and that was a simple case. Maybe that will give you an idea of the slowdown I'm experiencing on my end in getting things done.

comment:34 Changed 10 years ago by jordan

  • Resolution set to fixed
  • Status changed from new to closed

Closing inactive ticket for lack of information.

Fedora and Ubuntu now both have 2.3x builds in various repositories/ppas.

comment:35 follow-up: Changed 10 years ago by Astara

""Fedora and Ubuntu now both have 2.3x builds in various repositories/ppas. "" --- How this is relevant to this bug, filed against OpenSuSE, still built with older libraries, is beyond me. But OpenSuSE is only the 2nd or 3rd most used distro, (I think Ubuntu passed it several months ago), so maybe supporting the top 3 distro's is too much for this type of project -- though most larger open source products seem to work on many more, including those of different architecture. I wonder how well transmission will fare the first time it's run on a big-endian machine (may fare fine, but if it coughs on distros w/o the latest libs, hard to tell what would happen on alt-architectures).

Given its reliance on specialized libs, its likely that running it on any alternate platforms like BSD (I know special attention has been given to support it running on Windows, MUCH KUDOS for that effort -- getting anything to work there is often a miracle!) would be sketchy. But, that said, you can't do everything, though closing out a bug filed against openSuSE because it doesn't compile on said distro, is ... well... irresponsible.

If you wait, It's very likely, unless SuSE drops transmission from their distro, that this will be fixed within the next few months, as the needed lib and, presumably, transmission would be ported and tested within their framework. But certainly, this isn't a closed issued as far as "reality" goes, but expecting responsible, objective actions goes beyond my expectations.

The next version of OpenSuSE, I'm told, due for release in late 2011 or early 2012 (8 months after previous release whenever that was), will use the 2x library.

Meanwhile, I'm upgrading my local system to the latest OpenSuSE release (11.4). That, combined with openSuse's upgrade work might lead to this being solved. But certainly, closing it out because it works on unrelated distro's that are known to not use the same libs really is not appropriate, IMO, but, whatever...

comment:36 in reply to: ↑ 35 Changed 10 years ago by jordan

Replying to Astara:

But certainly, this isn't a closed issued as far as "reality" goes, but expecting responsible, objective actions goes beyond my expectations.

Lack of objective information is the reason the ticket is closed. It was filed over four months ago against version 2.20. Despite repeated requests, no debugging logs have been provided for version 2.20 or higher.

comment:37 Changed 10 years ago by Astara

That's because I couldn't get any version higher than that to compile on open suse due to your use of libraries that won't be included in opensuse until version 12.0 (skipping 11.5-11.9).

While I pointed at free resources for development and test (not just for opensuse, but other OS's as well are built upon the opensuse build platform(s)), and asked for your assistance, I was ignored. I can see in the comments above, that 3 months ago, the last thing asked for was some assistance in getting transmission to work on current versions -- either by including the sources of advanced-libs that you are using that, at the time were not in any distro (and still aren't in opensuse), or by getting the source (and libs) to compile on the suse build machines. I pointed at web addresses where you could make use of these tools.

You ignored those requests. That's why there is no more debug information. If you needed more debug information, you could have provided it -- but you chose not to.

It's not that I stopped you. I gave you the help I could and pointed at the resources to get what you wanted and asked for your assistance in providing in getting current versions to work on current versions of Opensuse.

Even now, you are pointing fingers at me for not providing more debug info, ignoring multiple requests for assistance and instead close out bugs that are still open due to your own level of diligence.

Note: See TracTickets for help on using tickets.