SMS not restoring

I'm using SMS Backup+ most recent version on Android 5.1.1 and SMS isn't restoring. I can tell that the program is connecting to my IMAP server (I use my own server not Google) because it backs up SMS perfectly and both backs up and restores my Call Log perfectly. So I know it's not a connection issue or a folder issue, but I can't figure out why it's not restoring. I tried turning on the log and enabling advanced logging in the hopes that that might point out the error but, while it created the log file, there was nothing in it after attempting a restore.

Seems like a problem with Gmail Imap PEEK command.
V/k9      (18941): conn1093162248>>> 7 UID FETCH 70628 (UID BODY.PEEK[])
It never gets the E-mail body. Not sure where is the problem with Gmail server or k9.mail library.
Looking for source code.

I am possibly experiencing the same thing: #601

On my phone it happened because I did not call:
BinaryTempFileBody.setTempDirectory(getCacheDir());
It is very strange relation, why if I did not set proper tmp directory imap fetch command hangs? Seems like internal bug.

@axet can you explain a bit better? why would you have to manually call this? it should be done as part of the initialization

@jberkel I'm debugging my code and find out k9mail do not throw exception when it is not properly initialised. More over, it hangs on "IMAP fetch" command. I'm not digging deeper, but you may...
Try it yourself, drop setTempDirectory call from RestoreTask and Restore hangs on IMAP fetch.
You can use those commands to see IMAP protocol:
            K9MailLib.setDebug(true);
            K9MailLib.setDebugSensitive(true);
            K9MailLib.DEBUG_PROTOCOL_IMAP = true;

My project is becoming a different app, more like android SMS gate using imap, it is not very useful to show the bug.
https://github.com/axet/sms-gate

@axet  ah ok, but that does not help with this particular bug since it is always guaranteed to be initialized. it think it's something else
@mobamoba unfortunately i can't help with this report other than suggesting to try with Gmail to make sure it's not related to your email server

@jberkel I think I could be related, because similar symptoms. But ... it may not be related.
Anyway it looks like a bug, since this situation is not handled correctly (I except library will throw an exception instead of hanging).

@jberkel I know with 100% certainty it's not my server as I've had this server setup for years and it's worked fine with prior versions of SMS Backup+. Also, the backup portion works so that tells us that the app is logging into my server and copying over SMS to the proper folder without problem.
I'm fairly certain it's Lollipop related (I'm using CM12.1) because I never had this issue with KitKat.
As I mentioned in my initial post the app has some kind of bug related with creating a log. I enable it in Advanced Settings along with the debug portion, but, when I go to View Log, it tells me "Log is empty. Enable it in "Advanced Settings."" I can see, in my file manager, that the log has been created, but nothing ever shows up it in it, meaning I can't give you more details about where the app is failing as I can't log anything.
However, I ran a Restore (as usual restored nothing; it asked If I wanted to make SMS Backup my default app - Yes - then, a few moments later, asked if I wanted to put my regular texting app back to default - Yes - then just stayed on "Calculating...") and copied the k9 portion from Catlog as perhaps that will help?
09-28 11:00:34.829 D/k9      (17370): Connecting to REDACTED as REDACTED
09-28 11:00:35.017 V/k9      (17370): conn360455677<<<#null# [OK, The Microsoft Exchange IMAP4 service is ready.]
09-28 11:00:35.017 D/k9      (17370): Saving [] capabilities for conn360455677
09-28 11:00:35.017 I/k9      (17370): Did not get capabilities in banner, requesting CAPABILITY for conn360455677
09-28 11:00:35.030 V/k9      (17370): conn360455677>>> 1 CAPABILITY
09-28 11:00:35.030 V/k9      (17370): conn360455677<<<#null# [CAPABILITY, IMAP4, IMAP4rev1, AUTH=NTLM, AUTH=GSSAPI, AUTH=PLAIN, IDLE, NAMESPACE, LITERAL+]
09-28 11:00:35.030 V/k9      (17370): conn360455677<<<#1# [OK, CAPABILITY completed.]
09-28 11:00:35.031 D/k9      (17370): Saving [NAMESPACE, AUTH=NTLM, IDLE, IMAP4, AUTH=GSSAPI, IMAP4REV1, LITERAL+, AUTH=PLAIN] capabilities for conn360455677
09-28 11:00:35.043 V/k9      (17370): conn360455677>>> 2 AUTHENTICATE PLAIN
09-28 11:00:35.043 V/k9      (17370): conn360455677<<<#+# []
09-28 11:00:35.118 V/k9      (17370): conn360455677<<<#2# [OK, AUTHENTICATE completed.]
09-28 11:00:35.118 D/k9      (17370): Saving [] capabilities for conn360455677
09-28 11:00:35.118 D/k9      (17370): COMPRESS=DEFLATE = false
09-28 11:00:35.118 D/k9      (17370): NAMESPACE = true, mPathPrefix = null
09-28 11:00:35.118 I/k9      (17370): pathPrefix is unset and server has NAMESPACE capability
09-28 11:00:35.119 V/k9      (17370): conn360455677>>> 3 NAMESPACE
09-28 11:00:35.132 V/k9      (17370): conn360455677<<<#null# [NAMESPACE, [[, /]], NIL, NIL]
09-28 11:00:35.132 V/k9      (17370): conn360455677<<<#3# [OK, NAMESPACE completed.]
09-28 11:00:35.133 D/k9      (17370): Got NAMESPACE response #null# [NAMESPACE, [[, /]], NIL, NIL] on conn360455677
09-28 11:00:35.133 D/k9      (17370): Got personal namespaces: [[, /]]
09-28 11:00:35.133 D/k9      (17370): Got first personal namespaces: [, /]
09-28 11:00:35.133 D/k9      (17370): Got path '' and separator '/'
09-28 11:00:35.133 D/k9      (17370): No detected folder auto-configuration methods.
09-28 11:00:35.175 D/k9      (17370): Connecting to REDACTED as REDACTED
09-28 11:00:35.394 V/k9      (17370): conn631900914<<<#null# [OK, The Microsoft Exchange IMAP4 service is ready.]
09-28 11:00:35.394 D/k9      (17370): Saving [] capabilities for conn631900914
09-28 11:00:35.394 I/k9      (17370): Did not get capabilities in banner, requesting CAPABILITY for conn631900914
09-28 11:00:35.395 V/k9      (17370): conn631900914>>> 1 CAPABILITY
09-28 11:00:35.402 V/k9      (17370): conn631900914<<<#null# [CAPABILITY, IMAP4, IMAP4rev1, AUTH=NTLM, AUTH=GSSAPI, AUTH=PLAIN, IDLE, NAMESPACE, LITERAL+]
09-28 11:00:35.402 V/k9      (17370): conn631900914<<<#1# [OK, CAPABILITY completed.]
09-28 11:00:35.403 D/k9      (17370): Saving [NAMESPACE, AUTH=NTLM, IDLE, IMAP4, AUTH=GSSAPI, IMAP4REV1, LITERAL+, AUTH=PLAIN] capabilities for conn631900914
09-28 11:00:35.403 V/k9      (17370): conn631900914>>> 2 AUTHENTICATE PLAIN
09-28 11:00:35.428 V/k9      (17370): conn631900914<<<#+# []
09-28 11:00:35.488 V/k9      (17370): conn631900914<<<#2# [OK, AUTHENTICATE completed.]
09-28 11:00:35.488 D/k9      (17370): Saving [] capabilities for conn631900914
09-28 11:00:35.488 D/k9      (17370): COMPRESS=DEFLATE = false
09-28 11:00:35.489 D/k9      (17370): NAMESPACE = true, mPathPrefix =
09-28 11:00:35.490 D/k9      (17370): Connecting to REDACTED as REDACTED
09-28 11:00:35.598 V/k9      (17370): conn32019779<<<#null# [OK, The Microsoft Exchange IMAP4 service is ready.]
09-28 11:00:35.598 D/k9      (17370): Saving [] capabilities for conn32019779
09-28 11:00:35.599 I/k9      (17370): Did not get capabilities in banner, requesting CAPABILITY for conn32019779
09-28 11:00:35.599 V/k9      (17370): conn32019779>>> 1 CAPABILITY
09-28 11:00:35.605 V/k9      (17370): conn32019779<<<#null# [CAPABILITY, IMAP4, IMAP4rev1, AUTH=NTLM, AUTH=GSSAPI, AUTH=PLAIN, IDLE, NAMESPACE, LITERAL+]
09-28 11:00:35.605 V/k9      (17370): conn32019779<<<#1# [OK, CAPABILITY completed.]
09-28 11:00:35.605 D/k9      (17370): Saving [NAMESPACE, AUTH=NTLM, IDLE, IMAP4, AUTH=GSSAPI, IMAP4REV1, LITERAL+, AUTH=PLAIN] capabilities for conn32019779
09-28 11:00:35.607 V/k9      (17370): conn32019779>>> 2 AUTHENTICATE PLAIN
09-28 11:00:35.657 V/k9      (17370): conn32019779<<<#+# []
09-28 11:00:35.715 V/k9      (17370): conn32019779<<<#2# [OK, AUTHENTICATE completed.]
09-28 11:00:35.715 D/k9      (17370): Saving [] capabilities for conn32019779
09-28 11:00:35.716 D/k9      (17370): COMPRESS=DEFLATE = false
09-28 11:00:35.716 D/k9      (17370): NAMESPACE = true, mPathPrefix =
09-28 11:00:35.718 V/k9      (17370): conn32019779>>> 3 STATUS "SMS" (UIDVALIDITY)
09-28 11:00:36.120 V/k9      (17370): conn32019779<<<#null# [STATUS, SMS, [UIDVALIDITY, 233]]
09-28 11:00:36.120 V/k9      (17370): conn32019779<<<#3# [OK, STATUS completed.]
09-28 11:00:36.126 V/k9      (17370): conn631900914>>> 3 NOOP
09-28 11:00:36.127 V/k9      (17370): conn631900914<<<#3# [OK, NOOP completed.]
09-28 11:00:36.129 V/k9      (17370): conn631900914>>> 4 SELECT "SMS"
09-28 11:00:36.657 V/k9      (17370): conn631900914<<<#null# [5956, EXISTS]
09-28 11:00:36.657 V/k9      (17370): conn631900914<<<#null# [0, RECENT]
09-28 11:00:36.657 V/k9      (17370): conn631900914<<<#null# [FLAGS, [\Seen, \Answered, \Flagged, \Deleted, \Draft, $MDNSent]]
09-28 11:00:36.657 V/k9      (17370): conn631900914<<<#null# [OK, [PERMANENTFLAGS, [\Seen, \Answered, \Flagged, \Deleted, \Draft, $MDNSent]], Permanent flags]
09-28 11:00:36.657 V/k9      (17370): conn631900914<<<#null# [OK, [UIDVALIDITY, 233], UIDVALIDITY value]
09-28 11:00:36.657 V/k9      (17370): conn631900914<<<#null# [OK, [UIDNEXT, 10799], The next unique identifier value]
09-28 11:00:36.658 V/k9      (17370): conn631900914<<<#4# [OK, [READ-WRITE], SELECT completed.]
09-28 11:00:36.687 D/k9      (17370): Got untagged EXISTS with value 5956 for com.zegoggles.smssync.mail.BackupStoreConfig@225427c0:SMS/AsyncTask #1/conn631900914
09-28 11:00:36.687 D/k9      (17370): Got UidNext = 10799 for com.zegoggles.smssync.mail.BackupStoreConfig@225427c0:SMS/AsyncTask #1/conn631900914
09-28 11:00:36.717 V/k9      (17370): conn631900914>>> 5 UID SEARCH 1:* (OR HEADER X-SMSSYNC-DATATYPE "SMS" (NOT HEADER X-SMSSYNC-DATATYPE "" (OR HEADER X-SMSSYNC-TYPE "1" HEADER X-SMSSYNC-TYPE "2"))) UNDELETED
09-28 11:00:37.092 V/k9      (17370): conn631900914<<<#null# [SEARCH]
09-28 11:00:37.092 V/k9      (17370): conn631900914<<<#5# [OK, SEARCH completed.]
09-28 11:00:37.100 V/k9      (17370): conn32019779>>> 4 NOOP
09-28 11:00:37.101 V/k9      (17370): conn32019779<<<#4# [OK, NOOP completed.]
09-28 11:00:37.448 D/k9      (17370): Connecting to REDACTED as REDACTED
09-28 11:00:37.618 V/k9      (17370): conn7445753<<<#null# [OK, The Microsoft Exchange IMAP4 service is ready.]
09-28 11:00:37.620 D/k9      (17370): Saving [] capabilities for conn7445753
09-28 11:00:37.620 I/k9      (17370): Did not get capabilities in banner, requesting CAPABILITY for conn7445753
09-28 11:00:37.624 V/k9      (17370): conn7445753>>> 1 CAPABILITY
09-28 11:00:37.640 V/k9      (17370): conn7445753<<<#null# [CAPABILITY, IMAP4, IMAP4rev1, AUTH=NTLM, AUTH=GSSAPI, AUTH=PLAIN, IDLE, NAMESPACE, LITERAL+]
09-28 11:00:37.640 V/k9      (17370): conn7445753<<<#1# [OK, CAPABILITY completed.]
09-28 11:00:37.640 D/k9      (17370): Saving [NAMESPACE, AUTH=NTLM, IDLE, IMAP4, AUTH=GSSAPI, IMAP4REV1, LITERAL+, AUTH=PLAIN] capabilities for conn7445753
09-28 11:00:37.648 V/k9      (17370): conn7445753>>> 2 AUTHENTICATE PLAIN
09-28 11:00:37.648 V/k9      (17370): conn7445753<<<#+# []
09-28 11:00:37.713 V/k9      (17370): conn7445753<<<#2# [OK, AUTHENTICATE completed.]
09-28 11:00:37.713 D/k9      (17370): Saving [] capabilities for conn7445753
09-28 11:00:37.713 D/k9      (17370): COMPRESS=DEFLATE = false
09-28 11:00:37.713 D/k9      (17370): NAMESPACE = true, mPathPrefix =
09-28 11:00:37.715 V/k9      (17370): conn32019779>>> 5 STATUS "Call log" (UIDVALIDITY)
09-28 11:00:37.732 V/k9      (17370): conn32019779<<<#null# [STATUS, Call log, [UIDVALIDITY, 214]]
09-28 11:00:37.732 V/k9      (17370): conn32019779<<<#5# [OK, STATUS completed.]
09-28 11:00:37.734 V/k9      (17370): conn7445753>>> 3 NOOP
09-28 11:00:37.738 V/k9      (17370): conn7445753<<<#3# [OK, NOOP completed.]
09-28 11:00:37.739 V/k9      (17370): conn7445753>>> 4 SELECT "Call log"
09-28 11:00:37.867 V/k9      (17370): conn7445753<<<#null# [96, EXISTS]
09-28 11:00:37.868 V/k9      (17370): conn7445753<<<#null# [0, RECENT]
09-28 11:00:37.868 V/k9      (17370): conn7445753<<<#null# [FLAGS, [\Seen, \Answered, \Flagged, \Deleted, \Draft, $MDNSent]]
09-28 11:00:37.869 V/k9      (17370): conn7445753<<<#null# [OK, [PERMANENTFLAGS, [\Seen, \Answered, \Flagged, \Deleted, \Draft, $MDNSent]], Permanent flags]
09-28 11:00:37.869 V/k9      (17370): conn7445753<<<#null# [OK, [UIDVALIDITY, 214], UIDVALIDITY value]
09-28 11:00:37.869 V/k9      (17370): conn7445753<<<#null# [OK, [UIDNEXT, 1121], The next unique identifier value]
09-28 11:00:37.869 V/k9      (17370): conn7445753<<<#4# [OK, [READ-WRITE], SELECT completed.]
09-28 11:00:37.869 D/k9      (17370): Got untagged EXISTS with value 96 for com.zegoggles.smssync.mail.BackupStoreConfig@225427c0:Call log/AsyncTask #1/conn7445753
09-28 11:00:37.870 D/k9      (17370): Got UidNext = 1121 for com.zegoggles.smssync.mail.BackupStoreConfig@225427c0:Call log/AsyncTask #1/conn7445753
09-28 11:00:37.871 V/k9      (17370): conn7445753>>> 5 UID SEARCH 1:* (HEADER X-SMSSYNC-DATATYPE "CALLLOG") UNDELETED
09-28 11:00:40.750 V/k9      (17370): conn7445753<<<#null# [SEARCH, 990, 991, 992, 993, 994, 995, 996, 997, 998, 999, 1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, 1009, 1010, 1011, 1012, 1013, 1014, 1015, 1016, 1017, 1018, 1019, 1020, 1052, 1053, 1054, 1055, 1056, 1057, 1058, 1059, 1060, 1061, 1062, 1063, 1064, 1065, 1066, 1067, 1068, 1069, 1070, 1071, 1072, 1073, 1074, 1075, 1076, 1077, 1078, 1079, 1080, 1081, 1082, 1083, 1084, 1085, 1086, 1087, 1088, 1089, 1090, 1091, 1092, 1093, 1094, 1095, 1096, 1097, 1098, 1103, 1104, 1105, 1106, 1107, 1108, 1109, 1110, 1111, 1112, 1113, 1114, 1115, 1116, 1117, 1118, 1119, 1120]
09-28 11:00:40.751 V/k9      (17370): conn7445753<<<#5# [OK, SEARCH completed.]
09-28 11:00:40.933 V/k9      (17370): conn7445753>>> 6 UID FETCH 990 (UID BODY.PEEK[])
09-28 11:00:41.069 V/k9      (17370): conn7445753<<<#null# [1, FETCH, [UID, 990, BODY, [], 1]]
09-28 11:00:41.069 V/k9      (17370): Stored uid '990' for msgSeq 1 into map
09-28 11:00:41.069 V/k9      (17370): conn7445753<<<#6# [OK, FETCH completed.]
09-28 11:00:41.292 V/k9      (17370): conn7445753>>> 7 UID FETCH 991 (UID BODY.PEEK[])
09-28 11:00:41.343 V/k9      (17370): conn7445753<<<#null# [2, FETCH, [UID, 991, BODY, [], 1]]
09-28 11:00:41.343 V/k9      (17370): Stored uid '991' for msgSeq 2 into map
09-28 11:00:41.344 V/k9      (17370): conn7445753<<<#7# [OK, FETCH completed.]
09-28 11:00:41.433 V/k9      (17370): conn7445753>>> 8 UID FETCH 992 (UID BODY.PEEK[])
09-28 11:00:41.487 V/k9      (17370): conn7445753<<<#null# [3, FETCH, [UID, 992, BODY, [], 1]]
09-28 11:00:41.487 V/k9      (17370): Stored uid '992' for msgSeq 3 into map
09-28 11:00:41.488 V/k9      (17370): conn7445753<<<#8# [OK, FETCH completed.]
09-28 11:00:41.690 V/k9      (17370): conn7445753>>> 9 UID FETCH 993 (UID BODY.PEEK[])
09-28 11:00:41.767 V/k9      (17370): conn7445753<<<#null# [4, FETCH, [UID, 993, BODY, [], 1]]
09-28 11:00:41.768 V/k9      (17370): Stored uid '993' for msgSeq 4 into map
09-28 11:00:41.768 V/k9      (17370): conn7445753<<<#9# [OK, FETCH completed.]
09-28 11:00:41.817 V/k9      (17370): conn7445753>>> 10 UID FETCH 994 (UID BODY.PEEK[])
09-28 11:00:41.849 V/k9      (17370): conn7445753<<<#null# [5, FETCH, [UID, 994, BODY, [], 1]]
09-28 11:00:41.849 V/k9      (17370): Stored uid '994' for msgSeq 5 into map
09-28 11:00:41.850 V/k9      (17370): conn7445753<<<#10# [OK, FETCH completed.]
09-28 11:00:41.871 V/k9      (17370): conn7445753>>> 11 UID FETCH 995 (UID BODY.PEEK[])
09-28 11:00:41.926 V/k9      (17370): conn7445753<<<#null# [6, FETCH, [UID, 995, BODY, [], 1]]
09-28 11:00:41.926 V/k9      (17370): Stored uid '995' for msgSeq 6 into map
09-28 11:00:41.926 V/k9      (17370): conn7445753<<<#11# [OK, FETCH completed.]
09-28 11:00:41.951 V/k9      (17370): conn7445753>>> 12 UID FETCH 996 (UID BODY.PEEK[])
09-28 11:00:42.027 V/k9      (17370): conn7445753<<<#null# [7, FETCH, [UID, 996, BODY, [], 1]]
09-28 11:00:42.027 V/k9      (17370): Stored uid '996' for msgSeq 7 into map
09-28 11:00:42.027 V/k9      (17370): conn7445753<<<#12# [OK, FETCH completed.]
09-28 11:00:42.144 V/k9      (17370): conn7445753>>> 13 UID FETCH 997 (UID BODY.PEEK[])
09-28 11:00:42.178 V/k9      (17370): conn7445753<<<#null# [8, FETCH, [UID, 997, BODY, [], 1]]
09-28 11:00:42.178 V/k9      (17370): Stored uid '997' for msgSeq 8 into map
09-28 11:00:42.178 V/k9      (17370): conn7445753<<<#13# [OK, FETCH completed.]
09-28 11:00:42.245 V/k9      (17370): conn7445753>>> 14 UID FETCH 998 (UID BODY.PEEK[])
09-28 11:00:42.297 V/k9      (17370): conn7445753<<<#null# [9, FETCH, [UID, 998, BODY, [], 1]]
09-28 11:00:42.297 V/k9      (17370): Stored uid '998' for msgSeq 9 into map
09-28 11:00:42.297 V/k9      (17370): conn7445753<<<#14# [OK, FETCH completed.]
09-28 11:00:42.379 V/k9      (17370): conn7445753>>> 15 UID FETCH 999 (UID BODY.PEEK[])
09-28 11:00:42.404 V/k9      (17370): conn7445753<<<#null# [10, FETCH, [UID, 999, BODY, [], 1]]
09-28 11:00:42.404 V/k9      (17370): Stored uid '999' for msgSeq 10 into map
09-28 11:00:42.404 V/k9      (17370): conn7445753<<<#15# [OK, FETCH completed.]
09-28 11:00:42.427 V/k9      (17370): conn7445753>>> 16 UID FETCH 1000 (UID BODY.PEEK[])
09-28 11:00:42.482 V/k9      (17370): conn7445753<<<#null# [11, FETCH, [UID, 1000, BODY, [], 1]]
09-28 11:00:42.482 V/k9      (17370): Stored uid '1000' for msgSeq 11 into map
09-28 11:00:42.482 V/k9      (17370): conn7445753<<<#16# [OK, FETCH completed.]
09-28 11:00:42.535 V/k9      (17370): conn7445753>>> 17 UID FETCH 1001 (UID BODY.PEEK[])
09-28 11:00:42.560 V/k9      (17370): conn7445753<<<#null# [12, FETCH, [UID, 1001, BODY, [], 1]]
09-28 11:00:42.561 V/k9      (17370): Stored uid '1001' for msgSeq 12 into map
09-28 11:00:42.561 V/k9      (17370): conn7445753<<<#17# [OK, FETCH completed.]
09-28 11:00:42.628 V/k9      (17370): conn7445753>>> 18 UID FETCH 1002 (UID BODY.PEEK[])
09-28 11:00:42.660 V/k9      (17370): conn7445753<<<#null# [13, FETCH, [UID, 1002, BODY, [], 1]]
09-28 11:00:42.660 V/k9      (17370): Stored uid '1002' for msgSeq 13 into map
09-28 11:00:42.660 V/k9      (17370): conn7445753<<<#18# [OK, FETCH completed.]
09-28 11:00:42.719 V/k9      (17370): conn7445753>>> 19 UID FETCH 1003 (UID BODY.PEEK[])
09-28 11:00:42.751 V/k9      (17370): conn7445753<<<#null# [14, FETCH, [UID, 1003, BODY, [], 1]]
09-28 11:00:42.751 V/k9      (17370): Stored uid '1003' for msgSeq 14 into map
09-28 11:00:42.751 V/k9      (17370): conn7445753<<<#19# [OK, FETCH completed.]
09-28 11:00:42.772 V/k9      (17370): conn7445753>>> 20 UID FETCH 1004 (UID BODY.PEEK[])
09-28 11:00:42.823 V/k9      (17370): conn7445753<<<#null# [15, FETCH, [UID, 1004, BODY, [], 1]]
09-28 11:00:42.823 V/k9      (17370): Stored uid '1004' for msgSeq 15 into map
09-28 11:00:42.823 V/k9      (17370): conn7445753<<<#20# [OK, FETCH completed.]
09-28 11:00:42.879 V/k9      (17370): conn7445753>>> 21 UID FETCH 1005 (UID BODY.PEEK[])
09-28 11:00:42.902 V/k9      (17370): conn7445753<<<#null# [16, FETCH, [UID, 1005, BODY, [], 1]]
09-28 11:00:42.902 V/k9      (17370): Stored uid '1005' for msgSeq 16 into map
09-28 11:00:42.903 V/k9      (17370): conn7445753<<<#21# [OK, FETCH completed.]
09-28 11:00:42.987 V/k9      (17370): conn7445753>>> 22 UID FETCH 1006 (UID BODY.PEEK[])
09-28 11:00:43.009 V/k9      (17370): conn7445753<<<#null# [17, FETCH, [UID, 1006, BODY, [], 1]]
09-28 11:00:43.009 V/k9      (17370): Stored uid '1006' for msgSeq 17 into map
09-28 11:00:43.009 V/k9      (17370): conn7445753<<<#22# [OK, FETCH completed.]
09-28 11:00:43.029 V/k9      (17370): conn7445753>>> 23 UID FETCH 1007 (UID BODY.PEEK[])
09-28 11:00:43.085 V/k9      (17370): conn7445753<<<#null# [18, FETCH, [UID, 1007, BODY, [], 1]]
09-28 11:00:43.085 V/k9      (17370): Stored uid '1007' for msgSeq 18 into map
09-28 11:00:43.086 V/k9      (17370): conn7445753<<<#23# [OK, FETCH completed.]
09-28 11:00:43.146 V/k9      (17370): conn7445753>>> 24 UID FETCH 1008 (UID BODY.PEEK[])
09-28 11:00:43.181 V/k9      (17370): conn7445753<<<#null# [19, FETCH, [UID, 1008, BODY, [], 1]]
09-28 11:00:43.181 V/k9      (17370): Stored uid '1008' for msgSeq 19 into map
09-28 11:00:43.181 V/k9      (17370): conn7445753<<<#24# [OK, FETCH completed.]
09-28 11:00:43.239 V/k9      (17370): conn7445753>>> 25 UID FETCH 1009 (UID BODY.PEEK[])
09-28 11:00:43.267 V/k9      (17370): conn7445753<<<#null# [20, FETCH, [UID, 1009, BODY, [], 1]]
09-28 11:00:43.267 V/k9      (17370): Stored uid '1009' for msgSeq 20 into map
09-28 11:00:43.267 V/k9      (17370): conn7445753<<<#25# [OK, FETCH completed.]
09-28 11:00:43.319 V/k9      (17370): conn7445753>>> 26 UID FETCH 1010 (UID BODY.PEEK[])
09-28 11:00:43.341 V/k9      (17370): conn7445753<<<#null# [21, FETCH, [UID, 1010, BODY, [], 1]]
09-28 11:00:43.341 V/k9      (17370): Stored uid '1010' for msgSeq 21 into map
09-28 11:00:43.342 V/k9      (17370): conn7445753<<<#26# [OK, FETCH completed.]
09-28 11:00:43.385 V/k9      (17370): conn7445753>>> 27 UID FETCH 1011 (UID BODY.PEEK[])
09-28 11:00:43.412 V/k9      (17370): conn7445753<<<#null# [22, FETCH, [UID, 1011, BODY, [], 1]]
09-28 11:00:43.412 V/k9      (17370): Stored uid '1011' for msgSeq 22 into map
09-28 11:00:43.412 V/k9      (17370): conn7445753<<<#27# [OK, FETCH completed.]
09-28 11:00:43.441 V/k9      (17370): conn7445753>>> 28 UID FETCH 1012 (UID BODY.PEEK[])
09-28 11:00:43.462 V/k9      (17370): conn7445753<<<#null# [23, FETCH, [UID, 1012, BODY, [], 1]]
09-28 11:00:43.462 V/k9      (17370): Stored uid '1012' for msgSeq 23 into map
09-28 11:00:43.464 V/k9      (17370): conn7445753<<<#28# [OK, FETCH completed.]
09-28 11:00:43.483 V/k9      (17370): conn7445753>>> 29 UID FETCH 1013 (UID BODY.PEEK[])
09-28 11:00:43.543 V/k9      (17370): conn7445753<<<#null# [24, FETCH, [UID, 1013, BODY, [], 1]]
09-28 11:00:43.543 V/k9      (17370): Stored uid '1013' for msgSeq 24 into map
09-28 11:00:43.543 V/k9      (17370): conn7445753<<<#29# [OK, FETCH completed.]
09-28 11:00:43.560 V/k9      (17370): conn7445753>>> 30 UID FETCH 1014 (UID BODY.PEEK[])
09-28 11:00:43.622 V/k9      (17370): conn7445753<<<#null# [25, FETCH, [UID, 1014, BODY, [], 1]]
09-28 11:00:43.622 V/k9      (17370): Stored uid '1014' for msgSeq 25 into map
09-28 11:00:43.622 V/k9      (17370): conn7445753<<<#30# [OK, FETCH completed.]
09-28 11:00:43.643 V/k9      (17370): conn7445753>>> 31 UID FETCH 1015 (UID BODY.PEEK[])
09-28 11:00:43.715 V/k9      (17370): conn7445753<<<#null# [26, FETCH, [UID, 1015, BODY, [], 1]]
09-28 11:00:43.715 V/k9      (17370): Stored uid '1015' for msgSeq 26 into map
09-28 11:00:43.715 V/k9      (17370): conn7445753<<<#31# [OK, FETCH completed.]
09-28 11:00:43.731 V/k9      (17370): conn7445753>>> 32 UID FETCH 1016 (UID BODY.PEEK[])
09-28 11:00:43.789 V/k9      (17370): conn7445753<<<#null# [27, FETCH, [UID, 1016, BODY, [], 1]]
09-28 11:00:43.789 V/k9      (17370): Stored uid '1016' for msgSeq 27 into map
09-28 11:00:43.789 V/k9      (17370): conn7445753<<<#32# [OK, FETCH completed.]
09-28 11:00:43.917 V/k9      (17370): conn7445753>>> 33 UID FETCH 1017 (UID BODY.PEEK[])
09-28 11:00:43.982 V/k9      (17370): conn7445753<<<#null# [28, FETCH, [UID, 1017, BODY, [], 1]]
09-28 11:00:43.982 V/k9      (17370): Stored uid '1017' for msgSeq 28 into map
09-28 11:00:43.982 V/k9      (17370): conn7445753<<<#33# [OK, FETCH completed.]
09-28 11:00:44.127 V/k9      (17370): conn7445753>>> 34 UID FETCH 1018 (UID BODY.PEEK[])
09-28 11:00:44.152 V/k9      (17370): conn7445753<<<#null# [29, FETCH, [UID, 1018, BODY, [], 1]]
09-28 11:00:44.152 V/k9      (17370): Stored uid '1018' for msgSeq 29 into map
09-28 11:00:44.152 V/k9      (17370): conn7445753<<<#34# [OK, FETCH completed.]
09-28 11:00:44.262 V/k9      (17370): conn7445753>>> 35 UID FETCH 1019 (UID BODY.PEEK[])
09-28 11:00:44.292 V/k9      (17370): conn7445753<<<#null# [30, FETCH, [UID, 1019, BODY, [], 1]]
09-28 11:00:44.292 V/k9      (17370): Stored uid '1019' for msgSeq 30 into map
09-28 11:00:44.293 V/k9      (17370): conn7445753<<<#35# [OK, FETCH completed.]
09-28 11:00:44.321 V/k9      (17370): conn7445753>>> 36 UID FETCH 1020 (UID BODY.PEEK[])
09-28 11:00:44.369 V/k9      (17370): conn7445753<<<#null# [31, FETCH, [UID, 1020, BODY, [], 1]]
09-28 11:00:44.369 V/k9      (17370): Stored uid '1020' for msgSeq 31 into map
09-28 11:00:44.369 V/k9      (17370): conn7445753<<<#36# [OK, FETCH completed.]
09-28 11:00:44.385 V/k9      (17370): conn7445753>>> 37 UID FETCH 1052 (UID BODY.PEEK[])
09-28 11:00:44.448 V/k9      (17370): conn7445753<<<#null# [32, FETCH, [UID, 1052, BODY, [], 1]]
09-28 11:00:44.449 V/k9      (17370): Stored uid '1052' for msgSeq 32 into map
09-28 11:00:44.449 V/k9      (17370): conn7445753<<<#37# [OK, FETCH completed.]
09-28 11:00:44.505 V/k9      (17370): conn7445753>>> 38 UID FETCH 1053 (UID BODY.PEEK[])
09-28 11:00:44.521 V/k9      (17370): conn7445753<<<#null# [33, FETCH, [UID, 1053, BODY, [], 1]]
09-28 11:00:44.521 V/k9      (17370): Stored uid '1053' for msgSeq 33 into map
09-28 11:00:44.522 V/k9      (17370): conn7445753<<<#38# [OK, FETCH completed.]
09-28 11:00:44.597 V/k9      (17370): conn7445753>>> 39 UID FETCH 1054 (UID BODY.PEEK[])
09-28 11:00:44.621 V/k9      (17370): conn7445753<<<#null# [34, FETCH, [UID, 1054, BODY, [], 1]]
09-28 11:00:44.622 V/k9      (17370): Stored uid '1054' for msgSeq 34 into map
09-28 11:00:44.622 V/k9      (17370): conn7445753<<<#39# [OK, FETCH completed.]
09-28 11:00:44.685 V/k9      (17370): conn7445753>>> 40 UID FETCH 1055 (UID BODY.PEEK[])
09-28 11:00:44.707 V/k9      (17370): conn7445753<<<#null# [35, FETCH, [UID, 1055, BODY, [], 1]]
09-28 11:00:44.707 V/k9      (17370): Stored uid '1055' for msgSeq 35 into map
09-28 11:00:44.707 V/k9      (17370): conn7445753<<<#40# [OK, FETCH completed.]
09-28 11:00:44.732 V/k9      (17370): conn7445753>>> 41 UID FETCH 1056 (UID BODY.PEEK[])
09-28 11:00:44.790 V/k9      (17370): conn7445753<<<#null# [36, FETCH, [UID, 1056, BODY, [], 1]]
09-28 11:00:44.791 V/k9      (17370): Stored uid '1056' for msgSeq 36 into map
09-28 11:00:44.791 V/k9      (17370): conn7445753<<<#41# [OK, FETCH completed.]
09-28 11:00:44.829 V/k9      (17370): conn7445753>>> 42 UID FETCH 1057 (UID BODY.PEEK[])
09-28 11:00:44.881 V/k9      (17370): conn7445753<<<#null# [37, FETCH, [UID, 1057, BODY, [], 1]]
09-28 11:00:44.881 V/k9      (17370): Stored uid '1057' for msgSeq 37 into map
09-28 11:00:44.881 V/k9      (17370): conn7445753<<<#42# [OK, FETCH completed.]
09-28 11:00:44.908 V/k9      (17370): conn7445753>>> 43 UID FETCH 1058 (UID BODY.PEEK[])
09-28 11:00:44.976 V/k9      (17370): conn7445753<<<#null# [38, FETCH, [UID, 1058, BODY, [], 1]]
09-28 11:00:44.976 V/k9      (17370): Stored uid '1058' for msgSeq 38 into map
09-28 11:00:44.976 V/k9      (17370): conn7445753<<<#43# [OK, FETCH completed.]
09-28 11:00:44.989 V/k9      (17370): conn7445753>>> 44 UID FETCH 1059 (UID BODY.PEEK[])
09-28 11:00:45.045 V/k9      (17370): conn7445753<<<#null# [39, FETCH, [UID, 1059, BODY, [], 1]]
09-28 11:00:45.047 V/k9      (17370): Stored uid '1059' for msgSeq 39 into map
09-28 11:00:45.047 V/k9      (17370): conn7445753<<<#44# [OK, FETCH completed.]
09-28 11:00:45.060 V/k9      (17370): conn7445753>>> 45 UID FETCH 1060 (UID BODY.PEEK[])
09-28 11:00:45.111 V/k9      (17370): conn7445753<<<#null# [40, FETCH, [UID, 1060, BODY, [], 1]]
09-28 11:00:45.111 V/k9      (17370): Stored uid '1060' for msgSeq 40 into map
09-28 11:00:45.112 V/k9      (17370): conn7445753<<<#45# [OK, FETCH completed.]
09-28 11:00:45.128 V/k9      (17370): conn7445753>>> 46 UID FETCH 1061 (UID BODY.PEEK[])
09-28 11:00:45.183 V/k9      (17370): conn7445753<<<#null# [41, FETCH, [UID, 1061, BODY, [], 1]]
09-28 11:00:45.183 V/k9      (17370): Stored uid '1061' for msgSeq 41 into map
09-28 11:00:45.183 V/k9      (17370): conn7445753<<<#46# [OK, FETCH completed.]
09-28 11:00:45.201 V/k9      (17370): conn7445753>>> 47 UID FETCH 1062 (UID BODY.PEEK[])
09-28 11:00:45.252 V/k9      (17370): conn7445753<<<#null# [42, FETCH, [UID, 1062, BODY, [], 1]]
09-28 11:00:45.252 V/k9      (17370): Stored uid '1062' for msgSeq 42 into map
09-28 11:00:45.253 V/k9      (17370): conn7445753<<<#47# [OK, FETCH completed.]
09-28 11:00:45.267 V/k9      (17370): conn7445753>>> 48 UID FETCH 1063 (UID BODY.PEEK[])
09-28 11:00:45.321 V/k9      (17370): conn7445753<<<#null# [43, FETCH, [UID, 1063, BODY, [], 1]]
09-28 11:00:45.321 V/k9      (17370): Stored uid '1063' for msgSeq 43 into map
09-28 11:00:45.323 V/k9      (17370): conn7445753<<<#48# [OK, FETCH completed.]
09-28 11:00:45.341 V/k9      (17370): conn7445753>>> 49 UID FETCH 1064 (UID BODY.PEEK[])
09-28 11:00:45.401 V/k9      (17370): conn7445753<<<#null# [44, FETCH, [UID, 1064, BODY, [], 1]]
09-28 11:00:45.401 V/k9      (17370): Stored uid '1064' for msgSeq 44 into map
09-28 11:00:45.402 V/k9      (17370): conn7445753<<<#49# [OK, FETCH completed.]
09-28 11:00:45.414 V/k9      (17370): conn7445753>>> 50 UID FETCH 1065 (UID BODY.PEEK[])
09-28 11:00:45.551 V/k9      (17370): conn7445753<<<#null# [45, FETCH, [UID, 1065, BODY, [], 1]]
09-28 11:00:45.551 V/k9      (17370): Stored uid '1065' for msgSeq 45 into map
09-28 11:00:45.551 V/k9      (17370): conn7445753<<<#50# [OK, FETCH completed.]
09-28 11:00:45.646 V/k9      (17370): conn7445753>>> 51 UID FETCH 1066 (UID BODY.PEEK[])
09-28 11:00:45.666 V/k9      (17370): conn7445753<<<#null# [46, FETCH, [UID, 1066, BODY, [], 1]]
09-28 11:00:45.666 V/k9      (17370): Stored uid '1066' for msgSeq 46 into map
09-28 11:00:45.667 V/k9      (17370): conn7445753<<<#51# [OK, FETCH completed.]
09-28 11:00:45.724 V/k9      (17370): conn7445753>>> 52 UID FETCH 1067 (UID BODY.PEEK[])
09-28 11:00:45.763 V/k9      (17370): conn7445753<<<#null# [47, FETCH, [UID, 1067, BODY, [], 1]]
09-28 11:00:45.763 V/k9      (17370): Stored uid '1067' for msgSeq 47 into map
09-28 11:00:45.763 V/k9      (17370): conn7445753<<<#52# [OK, FETCH completed.]
09-28 11:00:45.786 V/k9      (17370): conn7445753>>> 53 UID FETCH 1068 (UID BODY.PEEK[])
09-28 11:00:45.841 V/k9      (17370): conn7445753<<<#null# [48, FETCH, [UID, 1068, BODY, [], 1]]
09-28 11:00:45.841 V/k9      (17370): Stored uid '1068' for msgSeq 48 into map
09-28 11:00:45.842 V/k9      (17370): conn7445753<<<#53# [OK, FETCH completed.]
09-28 11:00:45.892 V/k9      (17370): conn7445753>>> 54 UID FETCH 1069 (UID BODY.PEEK[])
09-28 11:00:45.925 V/k9      (17370): conn7445753<<<#null# [49, FETCH, [UID, 1069, BODY, [], 1]]
09-28 11:00:45.925 V/k9      (17370): Stored uid '1069' for msgSeq 49 into map
09-28 11:00:45.925 V/k9      (17370): conn7445753<<<#54# [OK, FETCH completed.]
09-28 11:00:45.948 V/k9      (17370): conn7445753>>> 55 UID FETCH 1070 (UID BODY.PEEK[])
09-28 11:00:46.009 V/k9      (17370): conn7445753<<<#null# [50, FETCH, [UID, 1070, BODY, [], 1]]
09-28 11:00:46.009 V/k9      (17370): Stored uid '1070' for msgSeq 50 into map
09-28 11:00:46.009 V/k9      (17370): conn7445753<<<#55# [OK, FETCH completed.]
09-28 11:00:46.068 V/k9      (17370): conn7445753>>> 56 UID FETCH 1071 (UID BODY.PEEK[])
09-28 11:00:46.101 V/k9      (17370): conn7445753<<<#null# [51, FETCH, [UID, 1071, BODY, [], 1]]
09-28 11:00:46.101 V/k9      (17370): Stored uid '1071' for msgSeq 51 into map
09-28 11:00:46.102 V/k9      (17370): conn7445753<<<#56# [OK, FETCH completed.]
09-28 11:00:46.134 V/k9      (17370): conn7445753>>> 57 UID FETCH 1072 (UID BODY.PEEK[])
09-28 11:00:46.161 V/k9      (17370): conn7445753<<<#null# [52, FETCH, [UID, 1072, BODY, [], 1]]
09-28 11:00:46.162 V/k9      (17370): Stored uid '1072' for msgSeq 52 into map
09-28 11:00:46.162 V/k9      (17370): conn7445753<<<#57# [OK, FETCH completed.]
09-28 11:00:46.191 V/k9      (17370): conn7445753>>> 58 UID FETCH 1073 (UID BODY.PEEK[])
09-28 11:00:46.229 V/k9      (17370): conn7445753<<<#null# [53, FETCH, [UID, 1073, BODY, [], 1]]
09-28 11:00:46.229 V/k9      (17370): Stored uid '1073' for msgSeq 53 into map
09-28 11:00:46.230 V/k9      (17370): conn7445753<<<#58# [OK, FETCH completed.]
09-28 11:00:46.245 V/k9      (17370): conn7445753>>> 59 UID FETCH 1074 (UID BODY.PEEK[])
09-28 11:00:46.302 V/k9      (17370): conn7445753<<<#null# [54, FETCH, [UID, 1074, BODY, [], 1]]
09-28 11:00:46.302 V/k9      (17370): Stored uid '1074' for msgSeq 54 into map
09-28 11:00:46.302 V/k9      (17370): conn7445753<<<#59# [OK, FETCH completed.]
09-28 11:00:46.315 V/k9      (17370): conn7445753>>> 60 UID FETCH 1075 (UID BODY.PEEK[])
09-28 11:00:46.384 V/k9      (17370): conn7445753<<<#null# [55, FETCH, [UID, 1075, BODY, [], 1]]
09-28 11:00:46.384 V/k9      (17370): Stored uid '1075' for msgSeq 55 into map
09-28 11:00:46.399 V/k9      (17370): conn7445753<<<#60# [OK, FETCH completed.]
09-28 11:00:46.423 V/k9      (17370): conn7445753>>> 61 UID FETCH 1076 (UID BODY.PEEK[])
09-28 11:00:46.595 V/k9      (17370): conn7445753<<<#null# [56, FETCH, [UID, 1076, BODY, [], 1]]
09-28 11:00:46.596 V/k9      (17370): Stored uid '1076' for msgSeq 56 into map
09-28 11:00:46.686 V/k9      (17370): conn7445753<<<#61# [OK, FETCH completed.]
09-28 11:00:46.897 V/k9      (17370): conn7445753>>> 62 UID FETCH 1077 (UID BODY.PEEK[])
09-28 11:00:46.914 V/k9      (17370): conn7445753<<<#null# [57, FETCH, [UID, 1077, BODY, [], 1]]
09-28 11:00:46.914 V/k9      (17370): Stored uid '1077' for msgSeq 57 into map
09-28 11:00:46.915 V/k9      (17370): conn7445753<<<#62# [OK, FETCH completed.]
09-28 11:00:47.017 V/k9      (17370): conn7445753>>> 63 UID FETCH 1078 (UID BODY.PEEK[])
09-28 11:00:47.023 V/k9      (17370): conn7445753<<<#null# [58, FETCH, [UID, 1078, BODY, [], 1]]
09-28 11:00:47.023 V/k9      (17370): Stored uid '1078' for msgSeq 58 into map
09-28 11:00:47.023 V/k9      (17370): conn7445753<<<#63# [OK, FETCH completed.]
09-28 11:00:47.084 V/k9      (17370): conn7445753>>> 64 UID FETCH 1079 (UID BODY.PEEK[])
09-28 11:00:47.121 V/k9      (17370): conn7445753<<<#null# [59, FETCH, [UID, 1079, BODY, [], 1]]
09-28 11:00:47.121 V/k9      (17370): Stored uid '1079' for msgSeq 59 into map
09-28 11:00:47.121 V/k9      (17370): conn7445753<<<#64# [OK, FETCH completed.]
09-28 11:00:47.163 V/k9      (17370): conn7445753>>> 65 UID FETCH 1080 (UID BODY.PEEK[])
09-28 11:00:47.187 V/k9      (17370): conn7445753<<<#null# [60, FETCH, [UID, 1080, BODY, [], 1]]
09-28 11:00:47.187 V/k9      (17370): Stored uid '1080' for msgSeq 60 into map
09-28 11:00:47.188 V/k9      (17370): conn7445753<<<#65# [OK, FETCH completed.]
09-28 11:00:47.212 V/k9      (17370): conn7445753>>> 66 UID FETCH 1081 (UID BODY.PEEK[])
09-28 11:00:47.265 V/k9      (17370): conn7445753<<<#null# [61, FETCH, [UID, 1081, BODY, [], 1]]
09-28 11:00:47.265 V/k9      (17370): Stored uid '1081' for msgSeq 61 into map
09-28 11:00:47.266 V/k9      (17370): conn7445753<<<#66# [OK, FETCH completed.]
09-28 11:00:47.278 V/k9      (17370): conn7445753>>> 67 UID FETCH 1082 (UID BODY.PEEK[])
09-28 11:00:47.334 V/k9      (17370): conn7445753<<<#null# [62, FETCH, [UID, 1082, BODY, [], 1]]
09-28 11:00:47.334 V/k9      (17370): Stored uid '1082' for msgSeq 62 into map
09-28 11:00:47.334 V/k9      (17370): conn7445753<<<#67# [OK, FETCH completed.]
09-28 11:00:47.376 V/k9      (17370): conn7445753>>> 68 UID FETCH 1083 (UID BODY.PEEK[])
09-28 11:00:47.400 V/k9      (17370): conn7445753<<<#null# [63, FETCH, [UID, 1083, BODY, [], 1]]
09-28 11:00:47.400 V/k9      (17370): Stored uid '1083' for msgSeq 63 into map
09-28 11:00:47.401 V/k9      (17370): conn7445753<<<#68# [OK, FETCH completed.]
09-28 11:00:47.440 V/k9      (17370): conn7445753>>> 69 UID FETCH 1084 (UID BODY.PEEK[])
09-28 11:00:47.476 V/k9      (17370): conn7445753<<<#null# [64, FETCH, [UID, 1084, BODY, [], 1]]
09-28 11:00:47.476 V/k9      (17370): Stored uid '1084' for msgSeq 64 into map
09-28 11:00:47.476 V/k9      (17370): conn7445753<<<#69# [OK, FETCH completed.]
09-28 11:00:47.538 V/k9      (17370): conn7445753>>> 70 UID FETCH 1085 (UID BODY.PEEK[])
09-28 11:00:47.560 V/k9      (17370): conn7445753<<<#null# [65, FETCH, [UID, 1085, BODY, [], 1]]
09-28 11:00:47.560 V/k9      (17370): Stored uid '1085' for msgSeq 65 into map
09-28 11:00:47.560 V/k9      (17370): conn7445753<<<#70# [OK, FETCH completed.]
09-28 11:00:47.582 V/k9      (17370): conn7445753>>> 71 UID FETCH 1086 (UID BODY.PEEK[])
09-28 11:00:47.650 V/k9      (17370): conn7445753<<<#null# [66, FETCH, [UID, 1086, BODY, [], 1]]
09-28 11:00:47.651 V/k9      (17370): Stored uid '1086' for msgSeq 66 into map
09-28 11:00:47.651 V/k9      (17370): conn7445753<<<#71# [OK, FETCH completed.]
09-28 11:00:47.693 V/k9      (17370): conn7445753>>> 72 UID FETCH 1087 (UID BODY.PEEK[])
09-28 11:00:47.718 V/k9      (17370): conn7445753<<<#null# [67, FETCH, [UID, 1087, BODY, [], 1]]
09-28 11:00:47.719 V/k9      (17370): Stored uid '1087' for msgSeq 67 into map
09-28 11:00:47.719 V/k9      (17370): conn7445753<<<#72# [OK, FETCH completed.]
09-28 11:00:47.749 V/k9      (17370): conn7445753>>> 73 UID FETCH 1088 (UID BODY.PEEK[])
09-28 11:00:47.770 V/k9      (17370): conn7445753<<<#null# [68, FETCH, [UID, 1088, BODY, [], 1]]
09-28 11:00:47.770 V/k9      (17370): Stored uid '1088' for msgSeq 68 into map
09-28 11:00:47.770 V/k9      (17370): conn7445753<<<#73# [OK, FETCH completed.]
09-28 11:00:47.788 V/k9      (17370): conn7445753>>> 74 UID FETCH 1089 (UID BODY.PEEK[])
09-28 11:00:47.862 V/k9      (17370): conn7445753<<<#null# [69, FETCH, [UID, 1089, BODY, [], 1]]
09-28 11:00:47.862 V/k9      (17370): Stored uid '1089' for msgSeq 69 into map
09-28 11:00:47.863 V/k9      (17370): conn7445753<<<#74# [OK, FETCH completed.]
09-28 11:00:47.931 V/k9      (17370): conn7445753>>> 75 UID FETCH 1090 (UID BODY.PEEK[])
09-28 11:00:47.954 V/k9      (17370): conn7445753<<<#null# [70, FETCH, [UID, 1090, BODY, [], 1]]
09-28 11:00:47.954 V/k9      (17370): Stored uid '1090' for msgSeq 70 into map
09-28 11:00:47.955 V/k9      (17370): conn7445753<<<#75# [OK, FETCH completed.]
09-28 11:00:48.017 V/k9      (17370): conn7445753>>> 76 UID FETCH 1091 (UID BODY.PEEK[])
09-28 11:00:48.022 V/k9      (17370): conn7445753<<<#null# [71, FETCH, [UID, 1091, BODY, [], 1]]
09-28 11:00:48.022 V/k9      (17370): Stored uid '1091' for msgSeq 71 into map
09-28 11:00:48.022 V/k9      (17370): conn7445753<<<#76# [OK, FETCH completed.]
09-28 11:00:48.054 V/k9      (17370): conn7445753>>> 77 UID FETCH 1092 (UID BODY.PEEK[])
09-28 11:00:48.160 V/k9      (17370): conn7445753<<<#null# [72, FETCH, [UID, 1092, BODY, [], 1]]
09-28 11:00:48.160 V/k9      (17370): Stored uid '1092' for msgSeq 72 into map
09-28 11:00:48.160 V/k9      (17370): conn7445753<<<#77# [OK, FETCH completed.]
09-28 11:00:48.209 V/k9      (17370): conn7445753>>> 78 UID FETCH 1093 (UID BODY.PEEK[])
09-28 11:00:48.231 V/k9      (17370): conn7445753<<<#null# [73, FETCH, [UID, 1093, BODY, [], 1]]
09-28 11:00:48.231 V/k9      (17370): Stored uid '1093' for msgSeq 73 into map
09-28 11:00:48.231 V/k9      (17370): conn7445753<<<#78# [OK, FETCH completed.]
09-28 11:00:48.262 V/k9      (17370): conn7445753>>> 79 UID FETCH 1094 (UID BODY.PEEK[])
09-28 11:00:48.321 V/k9      (17370): conn7445753<<<#null# [74, FETCH, [UID, 1094, BODY, [], 1]]
09-28 11:00:48.321 V/k9      (17370): Stored uid '1094' for msgSeq 74 into map
09-28 11:00:48.321 V/k9      (17370): conn7445753<<<#79# [OK, FETCH completed.]
09-28 11:00:48.351 V/k9      (17370): conn7445753>>> 80 UID FETCH 1095 (UID BODY.PEEK[])
09-28 11:00:48.402 V/k9      (17370): conn7445753<<<#null# [75, FETCH, [UID, 1095, BODY, [], 1]]
09-28 11:00:48.402 V/k9      (17370): Stored uid '1095' for msgSeq 75 into map
09-28 11:00:48.402 V/k9      (17370): conn7445753<<<#80# [OK, FETCH completed.]
09-28 11:00:48.416 V/k9      (17370): conn7445753>>> 81 UID FETCH 1096 (UID BODY.PEEK[])
09-28 11:00:48.475 V/k9      (17370): conn7445753<<<#null# [76, FETCH, [UID, 1096, BODY, [], 1]]
09-28 11:00:48.475 V/k9      (17370): Stored uid '1096' for msgSeq 76 into map
09-28 11:00:48.475 V/k9      (17370): conn7445753<<<#81# [OK, FETCH completed.]
09-28 11:00:48.516 V/k9      (17370): conn7445753>>> 82 UID FETCH 1097 (UID BODY.PEEK[])
09-28 11:00:48.541 V/k9      (17370): conn7445753<<<#null# [77, FETCH, [UID, 1097, BODY, [], 1]]
09-28 11:00:48.541 V/k9      (17370): Stored uid '1097' for msgSeq 77 into map
09-28 11:00:48.542 V/k9      (17370): conn7445753<<<#82# [OK, FETCH completed.]
09-28 11:00:48.580 V/k9      (17370): conn7445753>>> 83 UID FETCH 1098 (UID BODY.PEEK[])
09-28 11:00:48.720 V/k9      (17370): conn7445753<<<#null# [78, FETCH, [UID, 1098, BODY, [], 1]]
09-28 11:00:48.720 V/k9      (17370): Stored uid '1098' for msgSeq 78 into map
09-28 11:00:48.726 V/k9      (17370): conn7445753<<<#83# [OK, FETCH completed.]
09-28 11:00:48.838 V/k9      (17370): conn7445753>>> 84 UID FETCH 1103 (UID BODY.PEEK[])
09-28 11:00:48.883 V/k9      (17370): conn7445753<<<#null# [79, FETCH, [UID, 1103, BODY, [], 1]]
09-28 11:00:48.883 V/k9      (17370): Stored uid '1103' for msgSeq 79 into map
09-28 11:00:48.883 V/k9      (17370): conn7445753<<<#84# [OK, FETCH completed.]
09-28 11:00:48.896 V/k9      (17370): conn7445753>>> 85 UID FETCH 1104 (UID BODY.PEEK[])
09-28 11:00:48.952 V/k9      (17370): conn7445753<<<#null# [80, FETCH, [UID, 1104, BODY, [], 1]]
09-28 11:00:48.953 V/k9      (17370): Stored uid '1104' for msgSeq 80 into map
09-28 11:00:48.953 V/k9      (17370): conn7445753<<<#85# [OK, FETCH completed.]
09-28 11:00:48.972 V/k9      (17370): conn7445753>>> 86 UID FETCH 1105 (UID BODY.PEEK[])
09-28 11:00:49.023 V/k9      (17370): conn7445753<<<#null# [81, FETCH, [UID, 1105, BODY, [], 1]]
09-28 11:00:49.023 V/k9      (17370): Stored uid '1105' for msgSeq 81 into map
09-28 11:00:49.023 V/k9      (17370): conn7445753<<<#86# [OK, FETCH completed.]
09-28 11:00:49.076 V/k9      (17370): conn7445753>>> 87 UID FETCH 1106 (UID BODY.PEEK[])
09-28 11:00:49.091 V/k9      (17370): conn7445753<<<#null# [82, FETCH, [UID, 1106, BODY, [], 1]]
09-28 11:00:49.091 V/k9      (17370): Stored uid '1106' for msgSeq 82 into map
09-28 11:00:49.091 V/k9      (17370): conn7445753<<<#87# [OK, FETCH completed.]
09-28 11:00:49.110 V/k9      (17370): conn7445753>>> 88 UID FETCH 1107 (UID BODY.PEEK[])
09-28 11:00:49.162 V/k9      (17370): conn7445753<<<#null# [83, FETCH, [UID, 1107, BODY, [], 1]]
09-28 11:00:49.162 V/k9      (17370): Stored uid '1107' for msgSeq 83 into map
09-28 11:00:49.163 V/k9      (17370): conn7445753<<<#88# [OK, FETCH completed.]
09-28 11:00:49.255 V/k9      (17370): conn7445753>>> 89 UID FETCH 1108 (UID BODY.PEEK[])
09-28 11:00:49.341 V/k9      (17370): conn7445753<<<#null# [84, FETCH, [UID, 1108, BODY, [], 1]]
09-28 11:00:49.341 V/k9      (17370): Stored uid '1108' for msgSeq 84 into map
09-28 11:00:49.344 V/k9      (17370): conn7445753<<<#89# [OK, FETCH completed.]
09-28 11:00:49.359 V/k9      (17370): conn7445753>>> 90 UID FETCH 1109 (UID BODY.PEEK[])
09-28 11:00:49.407 V/k9      (17370): conn7445753<<<#null# [85, FETCH, [UID, 1109, BODY, [], 1]]
09-28 11:00:49.407 V/k9      (17370): Stored uid '1109' for msgSeq 85 into map
09-28 11:00:49.407 V/k9      (17370): conn7445753<<<#90# [OK, FETCH completed.]
09-28 11:00:49.421 V/k9      (17370): conn7445753>>> 91 UID FETCH 1110 (UID BODY.PEEK[])
09-28 11:00:49.472 V/k9      (17370): conn7445753<<<#null# [86, FETCH, [UID, 1110, BODY, [], 1]]
09-28 11:00:49.472 V/k9      (17370): Stored uid '1110' for msgSeq 86 into map
09-28 11:00:49.472 V/k9      (17370): conn7445753<<<#91# [OK, FETCH completed.]
09-28 11:00:49.520 V/k9      (17370): conn7445753>>> 92 UID FETCH 1111 (UID BODY.PEEK[])
09-28 11:00:49.546 V/k9      (17370): conn7445753<<<#null# [87, FETCH, [UID, 1111, BODY, [], 1]]
09-28 11:00:49.547 V/k9      (17370): Stored uid '1111' for msgSeq 87 into map
09-28 11:00:49.547 V/k9      (17370): conn7445753<<<#92# [OK, FETCH completed.]
09-28 11:00:49.594 V/k9      (17370): conn7445753>>> 93 UID FETCH 1112 (UID BODY.PEEK[])
09-28 11:00:49.631 V/k9      (17370): conn7445753<<<#null# [88, FETCH, [UID, 1112, BODY, [], 1]]
09-28 11:00:49.632 V/k9      (17370): Stored uid '1112' for msgSeq 88 into map
09-28 11:00:49.632 V/k9      (17370): conn7445753<<<#93# [OK, FETCH completed.]
09-28 11:00:49.698 V/k9      (17370): conn7445753>>> 94 UID FETCH 1113 (UID BODY.PEEK[])
09-28 11:00:49.745 V/k9      (17370): conn7445753<<<#null# [89, FETCH, [UID, 1113, BODY, [], 1]]
09-28 11:00:49.745 V/k9      (17370): Stored uid '1113' for msgSeq 89 into map
09-28 11:00:49.745 V/k9      (17370): conn7445753<<<#94# [OK, FETCH completed.]
09-28 11:00:49.759 V/k9      (17370): conn7445753>>> 95 UID FETCH 1114 (UID BODY.PEEK[])
09-28 11:00:49.782 V/k9      (17370): conn7445753<<<#null# [90, FETCH, [UID, 1114, BODY, [], 1]]
09-28 11:00:49.783 V/k9      (17370): Stored uid '1114' for msgSeq 90 into map
09-28 11:00:49.783 V/k9      (17370): conn7445753<<<#95# [OK, FETCH completed.]
09-28 11:00:49.837 V/k9      (17370): conn7445753>>> 96 UID FETCH 1115 (UID BODY.PEEK[])
09-28 11:00:49.859 V/k9      (17370): conn7445753<<<#null# [91, FETCH, [UID, 1115, BODY, [], 1]]
09-28 11:00:49.859 V/k9      (17370): Stored uid '1115' for msgSeq 91 into map
09-28 11:00:49.859 V/k9      (17370): conn7445753<<<#96# [OK, FETCH completed.]
09-28 11:00:49.883 V/k9      (17370): conn7445753>>> 97 UID FETCH 1116 (UID BODY.PEEK[])
09-28 11:00:49.945 V/k9      (17370): conn7445753<<<#null# [92, FETCH, [UID, 1116, BODY, [], 1]]
09-28 11:00:49.945 V/k9      (17370): Stored uid '1116' for msgSeq 92 into map
09-28 11:00:49.945 V/k9      (17370): conn7445753<<<#97# [OK, FETCH completed.]
09-28 11:00:49.974 V/k9      (17370): conn7445753>>> 98 UID FETCH 1117 (UID BODY.PEEK[])
09-28 11:00:50.039 V/k9      (17370): conn7445753<<<#null# [93, FETCH, [UID, 1117, BODY, [], 1]]
09-28 11:00:50.039 V/k9      (17370): Stored uid '1117' for msgSeq 93 into map
09-28 11:00:50.039 V/k9      (17370): conn7445753<<<#98# [OK, FETCH completed.]
09-28 11:00:50.055 V/k9      (17370): conn7445753>>> 99 UID FETCH 1118 (UID BODY.PEEK[])
09-28 11:00:50.116 V/k9      (17370): conn7445753<<<#null# [94, FETCH, [UID, 1118, BODY, [], 1]]
09-28 11:00:50.116 V/k9      (17370): Stored uid '1118' for msgSeq 94 into map
09-28 11:00:50.116 V/k9      (17370): conn7445753<<<#99# [OK, FETCH completed.]
09-28 11:00:50.137 V/k9      (17370): conn7445753>>> 100 UID FETCH 1119 (UID BODY.PEEK[])
09-28 11:00:50.191 V/k9      (17370): conn7445753<<<#null# [95, FETCH, [UID, 1119, BODY, [], 1]]
09-28 11:00:50.191 V/k9      (17370): Stored uid '1119' for msgSeq 95 into map
09-28 11:00:50.191 V/k9      (17370): conn7445753<<<#100# [OK, FETCH completed.]
09-28 11:00:50.210 V/k9      (17370): conn7445753>>> 101 UID FETCH 1120 (UID BODY.PEEK[])
09-28 11:00:50.263 V/k9      (17370): conn7445753<<<#null# [96, FETCH, [UID, 1120, BODY, [], 1]]
09-28 11:00:50.263 V/k9      (17370): Stored uid '1120' for msgSeq 96 into map
09-28 11:00:50.264 V/k9      (17370): conn7445753<<<#101# [OK, FETCH completed.]

@axet out of curiosity, what is this app doing that you're building? is it already published?
@mobamoba not much has changed recently in the restore portion of the app. maybe lollipop / CM introduced some changes, it sounds like a permission problem. if the app does not have SMS write permission nothing will get restored. this is exactly the broken behaviour before kitkat support was added (see #475)

@jberkel I understand. But setting the app as default SMS gives it those write permissions, correct? In other words, it has them but still doesn't restore. Or is there some other permission that it needs that perhaps is a little screwy in CM12.1?

@mobamoba i have no idea, just guessing at this point. i know that CM had / has  some custom permission system (which got removed in stock android). maybe it's worth checking through preferences?

Oh you mean the Privacy Guard? You know, I think that might be the issue. It won't let your app write to the SMS DB nor will it allow me to manually change the permission (I change it to Allowed and it changes it back to Ignored). It seems to be a CM12.1 bug and not a bug with your program but thanks for helping me find it.

@jberkel here is an explanation:
https://github.com/axet/keneksi-sun

@mobamoba ok, good to know that it's something else. i'll close this issue for now, reopen if needed.


Cancelling IDE settings import does not work

If the "Adjust Intellij IDEA Settings" dialog is closed by X on title bar or by pressing Esc key, nothing should happen. (Now it is same as clicking OK).
Also the "you wanna restart now" dialog shouldn't have X in the title bar because that's "cancel" and not "no". (If the X is there, clicking it should cancel the whole thing)

we need to check if IntelliJ "yes"/"no" has the "X" greyed out


Desaturated colours when used with Watch Dogs 2

When using dxvk with watch dogs 2 to eliminate the sky flickering bug, for whatever reason, it causes the colours to become totally desaturated. I have no idea what the issue is but it is not resolved by changing any setting, full screen mode, or similar.
Geforce 4090
Ryzen 7 5800X

Hi there.
Please include logs and a apitrace. If the issue can be shown in a screenshot then also include two with and without dxvk.
Do you have a HDR monitor?

Besides the apitrace, could you also provide some screenshots of what it looks like with DXVK and what it's supposed to look like?

@OmegaTomHanks Friendly ping


[FLINK-10555] [test] Port AkkaSslITCase to new code base

What is the purpose of the change
Port AkkaSslITCase to new code base, as MiniClusterSslITCase.
Brief change log
Testing the flink cluster using SSL transport for akka remoting, use MiniCluster as "flink cluster".
Verifying this change
This change is a trivial rework and it itself is a test.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

cc @tillrohrmann @StephanEwen

With interaction I mean the communication between an external component and the MiniCluster components. For example, one could try to use the RestClient to talk to the MiniCluster. Or setup an RpcService to connect to one of the Flink RpcEndpoints. But the latter part should actually already be covered by RpcSSLAuthITCase which tests the SSL authentication between RpcEndpoints.

@tillrohrmann yes I think those are covered by the mentioned existing tests. Moving negative tests to BlobServerSslTest as suggested.

ping @tillrohrmann :-)
FYI travis fails on
Results :

Tests in error:
  KafkaITCase.testAllDeletes:131->KafkaConsumerTestBase.runAllDeletesTest:1526->KafkaTestBase.deleteTestTopic:206->Object.wait:502->Object.wait:-2 Â» TestTimedOut

Tests run: 45, Failures: 0, Errors: 1, Skipped: 0

which I think is irrelevant of this change, maybe I can do a rebase to fix it? not sure if fixed on master.

Sorry for being unresponsive @TisonKun. I'm currently busy with the next Flink release and will come back to that once 1.7 is out. Please bear with us until then.

re-push for resolving conflict.

ping @tillrohrmann as a reminder

rebase on master to resolve the irrelevant Kafka issue


Use two-byte checksum for unencrypted secret keys

Fixes #348 by unconditionally using a 2-byte checksum instead of SHA1 if encryption algorithm is NULL.

Thanks, this patch is actually correct and has been added.

Is this actually merged?
git tag --contains  81bca0133f19d5efac4857e0da8b772002545157

error: no such commit 81bca0133f19d5efac4857e0da8b772002545157


refactor(genetic): Improved roulette efficiency

Use choose_weighted instead of an infinite loop for increased performance and constant time.

Ah, I've refactored some use-s in the meantime and we ended up having conflicts - could you please rebase your branch?

Ah, I've refactored some use-s in the meantime and we ended up having conflicts - could you please rebase your branch?

Now it's ready

Now it's ready

And before this PR is over, let me thank you for creating this project. It covers very interesting topics (deep learning, rust, genetic algorithms) in a clear and simple that anyone can understand.

And before this PR is over, let me thank you for creating this project. It covers very interesting topics (deep learning, rust, genetic algorithms) in a clear and simple that anyone can understand.

Thanks, it means a lot!

Thanks, it means a lot!


Power platform custom business process article is confusing and needs expandsion

https://docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/custom-business-processes
I am not sure your description matches with the graph.
And in step 4, you probably meant stored instead of processed.
4. Azure Functions runs the Graph API calls, which are processed in Azure Storage
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: fe44a625-07a6-7d65-d16e-a8544c034261
Version Independent ID: 54310bdb-1397-cd5a-688c-f8e5c042a3fb
Content: Custom business processes - Azure Solution Ideas
Content Source: docs/solution-ideas/articles/custom-business-processes.yml
Service: architecture-center
Sub-service: solution-idea
GitHub Login: @EdPrice-MSFT
Microsoft Alias: edprice

@sdzhangtao Thanks for the feedback! I have assigned the issue to the content author to investigate further and update the document as appropriate.

@sdzhangtao - Great catch.
Edit made on this private PR: https://github.com/MicrosoftDocs/architecture-center-pr/pull/6647
ETA is noon PST, 6/22.

It appears this was addressed some time ago.  If assistance is still needed, please re-open the issue with additional information.


Waybar Only Showing Certain Icons

This is my first time posting on an online forum so sorry if I don't follow certain conventions.
This is my waybar config: https://pastebin.com/uLw8BYsL
And this is the output:

Yet when I run this waybar config where I put the group at the top and removed the test line: https://pastebin.com/LK7knADd
I got this output instead:

Thank you in advanced for anyone who manages to figure this out, it's been bugging me for a while
Edited: Accidentally put the same file twice

I have no idea what that test thing is about but looking at the second config file, you seem to have an extra } on line 84 just after on-click ... in hyprland/workspaces.
With the first config file, waybar didn't know what to do with everything in test, so it just skipped it.
In the second config file you removed test but left the closing bracket. Everything after that didn't get loaded.
I'm kind of surprised all that didn't throw an error.

Thanks, I can't test it out right now because I'm on windows but it seems like the most likely reason why.


Use a binary built locally for APT/RPM

What this PR does / why we need it
Before this PR, the scripts to build APT and RPM packages would download the tanzu binary from Github.  This was meant to use an SRP-compliant binary in the packages (VMware secure build process).
We plan on adding the building of the APT/RPM packages to the SRP-compliant build itself.  To prepare for this, this PR no longer downloads the binary from Github but uses the one built locally.  This means that when building these packages in an SRP-compliant environment at the same time as when the SRP-compliant binaries are built, the resulting packages will also be SRP-compliant.
This implies that when such packages are built on a developer's machine, they will not be SRP-compliant since they no longer use the SRP-compliant binary from Github.  This is not such a problem because it is already not possible to properly sign such packages on a developer's machine, so we already have to rely on the SRP-environment to build and sign these APT/RPM packages.
On a developer's machine, before running either make apt-package or make rpm-package, the CLI binary must be built (for linux) first by using make cross-build (or the quicker make build-cli-linux-amd64).  This is not enforced by the makefile (yet?) because the binary build is triggered differently when doing the full SRP-compliant build.
Which issue(s) this PR fixes

Fixes # N/A
Describe testing done for PR
Build apt-package without an artifacts directory should fail as the local build is not used:
$ \rm -rf artifacts
$ make apt-package
docker run --rm -e VERSION=v1.0.0-dev -e DEB_SIGNER= -v /Users/kmarc/git/tanzu-cli:/Users/kmarc/git/tanzu-cli ubuntu /Users/kmarc/git/tanzu-cli/hack/apt/build_package.sh
Get:1 http://ports.ubuntu.com/ubuntu-ports jammy InRelease [270 kB]
Get:2 http://ports.ubuntu.com/ubuntu-ports jammy-updates InRelease [119 kB]
Get:3 http://ports.ubuntu.com/ubuntu-ports jammy-backports InRelease [108 kB]
[...]
====================================
Building debian package for amd64...
====================================
cp: cannot stat '/Users/kmarc/git/tanzu-cli/hack/apt/../../artifacts/linux/amd64/cli/core/v1.0.0-dev/tanzu-cli-linux_amd64': No such file or directory
make: *** [apt-package-only] Error 1

Build rpm-package without an artifacts directory should fail as the local build is not used:
$ \rm -rf artifacts
$ make rpm-package
docker run --rm -e VERSION=v1.0.0-dev -e RPM_SIGNER= -v /Users/kmarc/git/tanzu-cli:/Users/kmarc/git/tanzu-cli fedora /Users/kmarc/git/tanzu-cli/hack/rpm/build_package.sh
Fedora 38 - aarch64                             4.8 MB/s |  79 MB     00:16
Fedora 38 openh264 (From Cisco) - aarch64       1.9 kB/s | 2.5 kB     00:01
Fedora Modular 38 - aarch64                     3.1 MB/s | 2.7 MB     00:00
Fedora 38 - aarch64 - Updates                   3.7 MB/s |  23 MB     00:06
Fedora Modular 38 - aarch64 - Updates           2.3 MB/s | 2.0 MB     00:00
Dependencies resolved.
================================================================================
 Package                       Arch      Version                Repo       Size
================================================================================
Installing:
 createrepo_c                  aarch64   0.21.1-1.fc38          updates    76 k
 rpm-build                     aarch64   4.18.1-3.fc38          updates    77 k
[...]
+ rm -rf /root/rpmbuild/BUILDROOT/tanzu-cli-1.0.0_dev-1.x86_64
+ mkdir -p /root/rpmbuild/BUILDROOT/tanzu-cli-1.0.0_dev-1.x86_64/usr/bin
+ cp -af /Users/kmarc/git/tanzu-cli/artifacts/linux/amd64/cli/core/v1.0.0-dev/tanzu-cli-linux_amd64 /root/rpmbuild/BUILDROOT/tanzu-cli-1.0.0_dev-1.x86_64/usr/bin/tanzu
cp: cannot stat '/Users/kmarc/git/tanzu-cli/artifacts/linux/amd64/cli/core/v1.0.0-dev/tanzu-cli-linux_amd64': No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.hYIR73 (%install)
    source_date_epoch_from_changelog set but %changelog is missing
    Bad exit status from /var/tmp/rpm-tmp.hYIR73 (%install)

RPM build warnings:

RPM build errors:
make: *** [rpm-package] Error 1

Build apt-package and install it locally:
$ \rm -rf hack/apt/_output/
$ make build-cli-linux-amd64
build linux-amd64 CLI with version: v1.0.0-dev

$ make apt-package
docker run --rm -e VERSION=v1.0.0-dev -e DEB_SIGNER= -v /Users/kmarc/git/tanzu-cli:/Users/kmarc/git/tanzu-cli ubuntu /Users/kmarc/git/tanzu-cli/hack/apt/build_package.sh
Get:1 http://ports.ubuntu.com/ubuntu-ports jammy InRelease [270 kB]
Get:2 http://ports.ubuntu.com/ubuntu-ports jammy-updates InRelease [119 kB]
Get:3 http://ports.ubuntu.com/ubuntu-ports jammy-backports InRelease [108 kB]
[...]
====================================
Building debian package for amd64...
====================================
dpkg-deb: building package 'tanzu-cli' in '/Users/kmarc/git/tanzu-cli/hack/apt/_output/tanzu-cli_1.0.0-dev_linux_amd64.deb'.
====================================
Building debian package for arm64...
====================================
dpkg-deb: building package 'tanzu-cli' in '/Users/kmarc/git/tanzu-cli/hack/apt/_output/tanzu-cli_1.0.0-dev_linux_arm64.deb'.
skip debsigning
docker run --rm -e VERSION=v1.0.0-dev -e DEB_SIGNER= -v /Users/kmarc/git/tanzu-cli:/Users/kmarc/git/tanzu-cli ubuntu /Users/kmarc/git/tanzu-cli/hack/apt/build_package_repo.sh
Get:1 http://ports.ubuntu.com/ubuntu-ports jammy InRelease [270 kB]
Get:2 http://ports.ubuntu.com/ubuntu-ports jammy-updates InRelease [119 kB]
[...]
====================================
Building debian package repo for amd64...
====================================
Exporting indices...
====================================
Building debian package repo for arm64...
====================================
Exporting indices...
skip debsigning

# Test the resulting package
$ docker run --rm -it -v $(pwd)/hack/apt/_output/apt:/tmp/apt ubuntu

root@f5f1fdade059:/# echo "deb file:///tmp/apt tanzu-cli-jessie main" | tee /etc/apt/sources.list.d/tanzu.list
deb file:///tmp/apt tanzu-cli-jessie main
root@f5f1fdade059:/# apt-get update --allow-insecure-repositories
Get:1 file:/tmp/apt tanzu-cli-jessie InRelease
Ign:1 file:/tmp/apt tanzu-cli-jessie InRelease
[...]
Get:22 http://ports.ubuntu.com/ubuntu-ports jammy-security/main arm64 Packages [564 kB]
Fetched 23.8 MB in 4s (5714 kB/s)
Reading package lists... Done
W: The repository 'file:/tmp/apt tanzu-cli-jessie Release' is not signed.
N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration details.

root@f5f1fdade059:/# apt install -y tanzu-cli --allow-unauthenticated
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  tanzu-cli
0 upgraded, 1 newly installed, 0 to remove and 13 not upgraded.
Need to get 0 B/39.9 MB of archives.
After this operation, 0 B of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
  tanzu-cli
Authentication warning overridden.
Get:1 file:/tmp/apt tanzu-cli-jessie/main arm64 tanzu-cli arm64 1.0.0-dev [39.9 MB]
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package tanzu-cli.
(Reading database ... 4389 files and directories currently installed.)
Preparing to unpack .../tanzu-cli_1.0.0-dev_arm64.deb ...
Unpacking tanzu-cli (1.0.0-dev) ...
Setting up tanzu-cli (1.0.0-dev) ...

root@f5f1fdade059:/# tanzu version
version: v1.0.0-dev
buildDate: 2023-06-23
sha: c2d0c0163

Build rpm-package and install it locally:
$ make build-cli-linux-amd64
build linux-amd64 CLI with version: v1.0.0-dev
$ \rm -rf hack/rpm/_output/

$ make rpm-package
docker run --rm -e VERSION=v1.0.0-dev -e RPM_SIGNER= -v /Users/kmarc/git/tanzu-cli:/Users/kmarc/git/tanzu-cli fedora /Users/kmarc/git/tanzu-cli/hack/rpm/build_package.sh
Fedora 38 - aarch64                             6.2 MB/s |  79 MB     00:12
Fedora 38 openh264 (From Cisco) - aarch64       2.8 kB/s | 2.5 kB     00:00
Fedora Modular 38 - aarch64                     1.4 MB/s | 2.7 MB     00:01
Fedora 38 - aarch64 - Updates                   3.9 MB/s |  23 MB     00:06
Fedora Modular 38 - aarch64 - Updates           1.1 MB/s | 2.0 MB     00:01
[...]
+ rm -rf /root/rpmbuild/BUILDROOT/tanzu-cli-1.0.0_dev-1.x86_64
+ mkdir -p /root/rpmbuild/BUILDROOT/tanzu-cli-1.0.0_dev-1.x86_64/usr/bin
+ cp -af /Users/kmarc/git/tanzu-cli/artifacts/linux/amd64/cli/core/v1.0.0-dev/tanzu-cli-linux_amd64 /root/rpmbuild/BUILDROOT/tanzu-cli-1.0.0_dev-1.x86_64/usr/bin/tanzu
[...]
RPM build warnings:
    source_date_epoch_from_changelog set but %changelog is missing
    Missing build-id in /root/rpmbuild/BUILDROOT/tanzu-cli-1.0.0_dev-1.aarch64/usr/bin/tanzu
skip rpmsigning packages
Directory walk started
Directory walk done - 2 packages
Temporary output repo path: /Users/kmarc/git/tanzu-cli/hack/rpm/_output/rpm/tanzu-cli/.repodata/
Preparing sqlite DBs
Pool started (with 5 workers)
Pool finished
skip rpmsigning repo

# Install the built RPM package
$ docker run --rm -it -v $(pwd)/hack/rpm/_output/rpm:/tmp/rpm fedora

[root@9021800e5542 /]# cat << EOF | sudo tee /etc/yum.repos.d/tanzu-cli.repo
[tanzu-cli]
name=Tanzu CLI
baseurl=file:///tmp/rpm/tanzu-cli
enabled=1
gpgcheck=0
EOF

[root@9021800e5542 /]# yum install -y tanzu-cli
Fedora 38 - aarch64                                                                                7.1 MB/s |  79 MB     00:11
[...]

Installed:
  tanzu-cli-1.0.0_dev-1.aarch64

Complete!

[root@9021800e5542 /]# tanzu version
version: v1.0.0-dev
buildDate: 2023-06-23
sha: c2d0c0163

Release note

Building local APT/RPM packages now uses a local build of the `tanzu` binary.

Additional information
Special notes for your reviewer

As a followup, it would be nice to retain the possibility to use the gh release as a source of the artifacts, but this looks good to me.


Iox #1323 remove cpptoml patch and fix cmake 3.23 warning for release 1.0

Pre-Review Checklist for the PR Author

[x] Code follows the coding style of CONTRIBUTING.md
[x] Tests follow the best practice for testing
[x] Changelog updated in the unreleased section including API breaking changes
[x] Branch follows the naming format (iox-#123-this-is-a-branch)
[x] Commits messages are according to this guideline

[x] Commit messages have the issue ID (iox-#123 commit text)
[x] Commit messages are signed (git commit -s)
[x] Commit author matches Eclipse Contributor Agreement (and ECA is signed)

[x] Update the PR title

Follow the same conventions as for commit messages
Link to the relevant issue

[x] Relevant issues are linked
[x] Add sensible notes for the reviewer
[ ] All checks have passed (except task-list-completed)
[x] Assign PR to reviewer

Notes for Reviewer

Backport of #1325 and #1310 to release 1.0 branch
Checklist for the PR Reviewer

[ ] Commits are properly organized and messages are according to the guideline
[ ] Code according to our coding style and naming conventions
[ ] Unit tests have been written for new behavior

[ ] Each unit test case has a unique UUID

[ ] Public API changes are documented via doxygen
[ ] Copyright owner are updated in the changed files
[ ] PR title describes the changes

Post-review Checklist for the PR Author

[ ] All open points are addressed and tracked via issues

References

Relates to #1323
Relates to #1311

@clalancette @Blast545
We add here the bugfix for cpptoml to prevent another CMake warning from https://github.com/eclipse-iceoryx/iceoryx/pull/1310
for the case that CMake 3.23 is used on galactic.
ROS CI build (ROS Galactic, Ubuntu Focal, packages-up-to rmw_cyclonedds_cpp)

Linux
Linux-aarch64
Windows

The question here is if we are allowed to make changes in galactic since it is already released.

@dkroenke AFAIK changes are allowed as long as they don't break API/ABI:
https://docs.ros.org/en/rolling/How-To-Guides/Package-maintainer-guide.html#backporting-to-released-distributions


UI stopped showing the list of signees

We've been using CLA Assistant for a few months already.
I have just noticed that the list of signees is not available in the UI anymore. We use "Shared Gist". We used to be able to export the CSV by clicking on the link under the "Contributors" column. It used to take 2-3 minutes for this link to become visible in the UI though. Now it does not appear even though we wait.
URL to the linked Repo/Org:
https://github.com/jfrog/jfrog-idea-plugin
As I mentioned, we use "Shared Gist", so there are other repos under the same GitHub org which are connected and use the same CLA.
Thanks in advanced for your assistance.

We really need your help with this...
Any idea how to resolve this issue?

It would be helpful for us if you could send us a screenshot of the problem, you have described and time when the screenshot is made.

Sure @kborchers,
See the following two screenshots. They cover the entire screen (I couldn't fir everything into one image).
I took both of them now (12.20.47 GMT +2)
Please let me know if you need addition information.
Thanks!

@eyalbe4 I think you meant to mention @KharitonOff 😄

Indeed! My apologies @kborchers!
I meant to mention @KharitonOff :)

@eyalbe4 unfortunately I do not have a solution for the problem yet...
But looking at your list I think it would make sense for you to link the whole org once instead of linking each repository separately. Are there any reasons not to do so?

@KharitonOff - I think we'll do so.
Is this only a UI issue? Can you please retrieve the signees CSV for me?

@KharitonOff,
Sorry for nagging about this, but we really need the CSV export. If the UI issue cannot be resolved for now, that's fine, we'll come up with a different approach that does not rely on it, but all we need is to receive the stored CSV export.
I'd rally appreciate your quick assistance with this!

@KharitonOff - the issue is resolved! Thanks!!

I am glad, that the issue is resolved for you now, thanks for letting us know. It seems to be a UI issue, I could not find anything in our server logs... I would suggest to link the whole org and import the signatures there. You can easily unlink current repos, the list of signatures doesn't get lost.


lxd/storage: Add a ceph.rbd.du storage option to disable the use of rbd du

Resolves #9348.
Should I also add the new storage option to the Ceph storage config keys test in lxd/test/suites/storage_driver_ceph.sh?

I think what you have here is fine, but as this adds a new config key, you should add an extra commit:

api: Add ceph_rbd_du

Which will contain an addition to both doc/api-extensions.md and shared/version/api.go with an entry of the same name.

jenkins: test this please

Going to add that commit myself as we're about to tag a release and I'd like this in there.


Use ThemeIcon.color for QuickInputButton

I'm building a custom QuickPick that has a few QuickInputButtons that toggle whether certain items are shown/hidden. Right now I update the tooltip to reflect that pressing the button again will perform the opposite action, but I would like to also change the icon color to reflect that a certain feature is on or off (for example, use button.foreground when on and button.secondaryForeground when off).

Since the API takes in ThemeIcon we should support this.

Thanks for picking this up @TylerLeonhardt!

@TylerLeonhardt Any chance this makes it into a release soon?

At the moment, it's not a high enough priority compared to other things, sorry. That could change in the future. That said, PRs always welcome!
The issue here is that we turn ThemeIcons into classes here:
https://github.com/microsoft/vscode/blob/5fd8a4d5ccbc9f81c498d371a7a83de522c625d1/src/vs/workbench/api/common/extHostQuickOpen.ts#L522
but those classes don't carry along the color... I think what we need to do is plumb ThemeIcon through, rather than turning it into a class so that we can access the color when we render the button here:
https://github.com/microsoft/vscode/blob/5fd8a4d5ccbc9f81c498d371a7a83de522c625d1/src/vs/platform/quickinput/browser/quickInput.ts#L402
and
https://github.com/microsoft/vscode/blob/5fd8a4d5ccbc9f81c498d371a7a83de522c625d1/src/vs/platform/quickinput/browser/quickInputList.ts#L359
and here:
https://github.com/microsoft/vscode/blob/5fd8a4d5ccbc9f81c498d371a7a83de522c625d1/src/vs/platform/quickinput/browser/quickInputList.ts#L305-L308


Self-cleaning 28 days trash bin (optional) #117

Now you can move note to trash and remove auto after 28 days also you can restore Implement screen trash note
Also Fix one issue for edit note always empty data

Fix the merge conflicts @salmanA169.

Hey @salmanA169 there is an issue regarding your PR that I have found out after merging it into develop so I reverted back your changes.
The issue is that after saving the notes when the user clicks on the note and wants to edit it it shows a black screen I tried to debug it but couldn't find any solution.
So I prefer you to test once again and create a PR with the proper fix.
I hope you got it.


Temporary view _role_table_grants not dropping after function call

Have to wrap function body in transaction;

I have made this modification, that seems to work in my case: I have modified your script so that it has temporary tables instead of temporary views, and adding the "ON COMMIT DROP" statement on their creation. Then, I surround my alteration scripts with commits. In this way, it seems to work, albeit being slightly slower than using temporary views.

@oscarfanchin Any chance you could share code? My SQL foo is not strong. I can't get pas a ERROR: relation "_role_table_grants" already exists error. Wrapping things in transactions doesn't seem to change that outcome.

Unrelated, I love Postgres, but views make me want to take a warm bath with a razor blade. We have to use them for Hasura, and in theory their are a great idea. In practice having to manually drop and recreate an ENTIRE view chain just so I can update a timestamp from timestamp to timestamptz is an infuriating experience. We use Prisma for schema migrations, but they don't yet support views. Even if they did, it would puke out thousands of lines of DDL to drop/create the views every migration...
(╯°□°）╯︵ ┻━┻

facing the same error as @AThilenius here -- help would be appreciated!

I faced the same issue on Pg 16, even though my alter scripts were encapsulated in a BEGIN; ... COMMIT; block.
If I'm not misinformed, this can be expected within the same session, because temporary views aren't dropped after a transaction but at the end of a session.
Three possible remedies that I see:

Use temp tables instead, as @oscarfanchin suggested. However, view are more lightweight and should be preferred imho.
Emulate an if not exists clause by capturing SQLSTATE '42P07' in an EXCEPTION handler.
Use create or replace to work around the issue. I tried this approach first and it worked for me, so I stuck with it and sent this as a pull request.

BTW, thanks for sharing your work, @rvkulikov!


Help an idiot?

Hey! I realize this repo is a few years old, but it's PERFECT for a little game I'm setting up. Can you give me some tips on how to get it running?

I tried the usual "npm install" etc, locally, and couldn't figure it out
I tried deploying to Netlify, and the build works, but then still getting "Not Found" on the main URL

Any ideas? Thanks in advance!

Hello @clarklab, at the time the project was made, it was installed using yarn and used Webpack to build the app.
I will be doing an update in a few days to use the latest versions and add information to the readme.
Glad that my project is helpful to you anyways!
I'll leave the issue open and will respond once the update is done :)

Hey thanks! I got it building in the meantime, it turns out it wasn't working with my newer version of node. I swapped to Node 16 and everything built fine!
I'll keep an eye out for any updates.
PS: I'm using it to make a soundboard for the party game Werewolf (howls, growls, night, morning, etc)


verify_signature(): handle SerializationError

Fixes #1816
Description of the changes being introduced by the pull request:
We should handle the possible SerializationError inside
Key.verify_signature(), because the user of this API is not interested
in SerializationError when he is trying to verify his signature.
Note that the SerializationError can be thrown when calling
signed_serializer.serialize() on the metadata signed part.
Signed-off-by: Martin Vrachev<EMAIL_ADDRESS>Please verify and check that the pull request fulfills the following
requirements:

[ ] The code follows the Code Style Guidelines
[ ] Tests have been added for the bug fix or new feature
[ ] Docs have been added for the bug fix or new feature

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 98.082%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1114

Relevant Lines:
1132

💛  - Coveralls


dont know how to get multiple entries in formdata using request.files

Environment:

Python version: 3.11.4
Quart version: 0.18.4

request.files.getlist

request.files.getlist(key)

i tried before and it's not recognize the getlist.

this is the error when i use the getlist
AttributeError: 'coroutine' object has no attribute 'getlist'

files = await request.files
files.getlist(key)

https://quart.palletsprojects.com/en/latest/how_to_guides/flask_migration.html#async-and-await


🐛 BUG:

Which Cloudflare product(s) does this pertain to?
D1
What version(s) of the tool(s) are you using?
wrangler 3.15
What version of Node are you using?
8.19.2
What operating system are you using?
Mac
Describe the Bug
A request to the Cloudflare API (/accounts/{ID}/workers/scripts/{Worker-NAME) failed.
binding DB of type d1 failed to generate. Please try again later or contact support.
[code: 10021]
If you think this is a bug, please open an issue at:
https://github.com/cloudflare/workers-sdk/issues/new/choose
Please provide a link to a minimal reproduction
No response
Please provide any relevant error logs
In local works fine, also in production, now wrangler tell me that isn't valid, but, there are also some Scheduled maintenance today 3 nov

wrangler d1 execute networkloop --command='SELECT * FROM Customers'
🌀 Mapping SQL input into an array of statements
🌀 Parsing 1 statements
🌀 Executing on networkloop (d38dc410-ab11-42f2-ad97-fd8bc6dfb56e):
✘ [ERROR] Received a malformed response from the API

  <!--[if I... (length = 6433)

  POST
  /accounts/55261eacfb61dc9497adf0dbf499a695/d1/database/d38dc410-ab11-42f2-ad97-fd8bc6dfb56e/query
  -> 504 Gateway Time-out

  If you think this is a bug, please open an issue at:
  https://github.com/cloudflare/workers-sdk/issues/new/choose

This is likely a consequence of https://www.cloudflarestatus.com/incidents/hm7491k53ppg—could you try again?
If it's not resolved, feel free to comment with more details (error logs etc...) and we can investigate further


Memoisation of some PDF primitives

At present using some primitive objects such as PdfReal or PdfInteger is relatively expensive because using, say, the same number several times results in separate objects being created.  It may prove more efficient to create these using a factory method that caches the created objects.

Started working on a trial version of this, but on a non-typical dataset (creation of 2,000,000 random PdfInteger objects) performance was much, much slower than without it, so for now this is on hold in branch.


[azservicebus] Adding a timeout so link closures have a maximum of 60 seconds before they are cancelled.

Adding a timeout so link closures have a maximum of 60 seconds before they time out. This fixes an issue that came up when I made a fix in the last release to not timeout on close (since that can leave us in an inconsistent state). This surfaced an interesting problem where customers do see Close() hang.
So this adds in a timeout instead, which will cause us to close the connection to avoid inconsistency and also to recover overall since it's likely there's a problem that will require a more thorough reset than a simple link detach/reattach would give us.
As part of this I also created some more thorough mocks that test more of the connection/open behavior as well as links, ensuring that we do cleanup and end up in the state that we want. It's not 100% complete but it's good enough for this kind of testing and can be expanded.

/azp run go - azservicebus

/azp run go - azservicebus

/azp run go - azservicebus

Now that these changes have reached the main branch, when can we expect them to land in a new https://github.com/Azure/azure-sdk-for-go version?

Now that these changes have reached the main branch, when can we expect them to land in a new https://github.com/Azure/azure-sdk-for-go version?

Yes, it'll go out with the next regular release (next week).


Feature/#18 add headers in requests

Adds headers in the /status request, and query params clientName and clientVersion to pass to the checkout url.

@alfonso-paella you mean with the publish command? I guess that when you bump a package version, you would need to build and then publish. If the postbuild hook works as expected on the release process, I would assume that the prebuild would work as well.
How do you normally handle the release process? Maybe @mPaella knows too.
Thanks!


Error: getTokens Error

Hi All,
Trying to create an order using the script and everything works fine up until I run the create order command and get the error below:
getTokens Error invalid_grant
.../example-dfp-line-item-generator/node_modules/node-google-dfp/lib/DfpUser.js:69
throw error;
^
Any ideas?

Hi @brianibok, I think this problem has to do with authentication.
I found a couple links that could be useful:

https://groups.google.com/forum/#!topic/google-doubleclick-for-publishers-api/ogoaTEIJeCI
http://stackoverflow.com/questions/34027713/google-oauth2-access-token-invalid-grant

In the future, I think this type of question might be better fit for either the double click for publishers support forum, or for stackoverflow, since I don't think it's a problem with this library.
Best of luck!


Removing of deprecated builders suffixed by OrThrow

Description
Like discussed in the idea #104, we would like to remove deprecated builders suffixed by OrThrow.
Dependencies
This issue is blocked by the following ones:

[x] #120

Checklist

[ ] Remove deprecated builders with a hidden level.
[ ] Test.
[ ] Refactor.
[ ] Check the generated documentation.
[ ] Check and update the public API binaries.
[ ] Update the Unreleased section in changelog.

These type converters suffixed by OrThrow will be removed in the issue #258.


In TableRebalancer, allow increasing from 1 replica without downtime

Currently when rebalancing a table without downtime, the min available replicas check is performed on the min replica of current and target assignment. This will prevent user from increasing the replica of the table from 1 without downtime. This PR fixes that by only rely on target assignment to decide the min available replicas.

Codecov Report

Merging #7532 (6e82cec) into master (7be21c8) will decrease coverage by 57.27%.
The diff coverage is 100.00%.

@@              Coverage Diff              @@
##             master    #7532       +/-   ##
=============================================
- Coverage     72.54%   15.27%   -57.28%
+ Complexity     3405       80     -3325
=============================================
  Files          1523     1477       -46
  Lines         75653    73802     -1851
  Branches      11032    10833      -199
=============================================
- Hits          54880    11270    -43610
- Misses        17078    61720    +44642
+ Partials       3695      812     -2883

Flag
Coverage Δ

integration1
?

integration2
?

unittests1
?

unittests2
15.27% <100.00%> (+<0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 19f66fd...6e82cec. Read the comment docs.


multiple processes on windows

I'm running flask on windows, which calls run_simple, and when I set processes=2 I get errors.
It looks like this package calls SocketServer.py (python source code), which calls os.fork(), which windows doesn't support. Is there a good windows workaround?

The server is a development server and not intended for production.  Use cherrypy on windows if you need multiple processes.


Rename ta.DataFrame/Column to ta.dataframe/column

Summary: This is the first step; in follow-up diff will rename IDataFrame/IColumn -> DataFrame/Column
Differential Revision: D34411896

See https://github.com/facebookresearch/torcharrow/issues/185


python2Packages.wcwidth: fix build

python2Packages.wcwidth is disabled in https://github.com/NixOS/nixpkgs/pull/289229/files#diff-e3660b6955728047c993d60ff4af021e2f83ac4b8abd771938015a31141dc913R14. However, as of version 0.2.13 upstream still supports python2, so we re-enabled it in this commit. In the future, this package should be dropped or pinned to the last working version after upstream's final release for python2. See:

https://github.com/jquast/wcwidth/pull/117#issuecomment-1946609638

Friendly ping @fabaff for comments :wink:
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[x] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@ofborg build python2Packages.wcwidth

ofborg build python2Packages.wcwidth

Hey thank you for the quick response! I guess ofborg would not be helpful though, as python2 has been marked insecure. I tried building locally with config.allowInsecure and it seems to be working fine.

Yes, ofborg can't help here.

Oh nice thank you very much for merging this!


The top right search button does not allow returning list of all documents

Describe the issue
Earlier, if you typed for example word "test" for top right Document Search text box, and hit enter it returned you similar list you get when you type test on the main search page. Now if you type "test" there and hit enter, you get the first hit, you cannot get the list of documents matching your query.
Code of Conduct

[X] I agree to follow the IETF's Code of Conduct

Robert Sparks writes:

This change in behavior was made at request. Perhaps the thing to do
is add an "open as list" link to the list displayed?

That was my plan, was mostly debating, whether it should be done in
the javascript in ietf/static/js/select2.js:setupSelect2Field, or
whether to do it in the
ietf/doc/views_search.py:ajax_select2_search_docs. If the link comes
from the python code then we can use python to generate the url
correctly with correct search terms, but then the API call is not that
clean as there will be one extra item in the list which is not a
information about documents...
@.***

We are already building a mechanism for the front-end to know how to build certain URLs without having to ask django to do it (at least at runtime). I think in this case, the basic form of the URL is going to be really static, with whatever went into the box being the only variant?

Wasn't this fixed?

It may have morphed, but I'm not sure the issue has actually been addressed.
@kivinen Do you think it still needs to do something other than what it does now?
I do note that if you type multiple into the search box, for instance, you cannot get to draft-ietf-sipcore-multiple-reasons. It shows a list but has a number of results cutoff (as the main page does, but this one is much shorter).
You can get to the draft from that search bar, but you have to type more matching characters.

Lars Eggert writes:

Wasn't this fixed?

We discussed this during the codesprint and the main question was
whether this is implemented in the javascript or in the django code.
I.e., whether the API that the search function is using from
javascript should return one extra item that will do the full search
with the given string, or whether the javascript should automatically
always add one entry at the end that will do the full search using the
string typed in.
I did not implement it during the codesprint as I did not really get
agreement which way is better way to do it. Doing it in django, i.e.
modifying the API would allow us to only include it if the list of
items is truncated, but then the API would not be that clean as there
would be one extra item there which is not really single draft.
Doing it in the javascript means that the javascript needs to know how
to form the search url, i.e., if the main search function changes this
needs to be updated too... In django we can use methods that will get
changed if the url changes...
@.***

The above mention was a typo that should have been 4079. This ticket is not related to 5597.


Still no api for keeping playback rate speed when changing media source

Still no api for keeping playback rate speed when changing media source

文档详细信息
⚠ 请勿编辑此部分。 docs.microsoft.com ➟ GitHub 问题链接必须具有此部分。

ID: c68dc509-816d-26b2-4e61-c87e52171b6b
Version Independent ID: 7d8d4517-28f1-19e5-a102-6bfa4ce21173
Content: Windows 10 Build 19041 API changes - UWP applications
Content Source: windows-apps-src/whats-new/windows-10-build-19041-api-diff.md
Product: uwp
Technology: whats-new
GitHub Login: @QuinnRadich
Microsoft Alias: quradic

While we appreciate your feedback, this doesn't seem like a documentation issue. I'd recommend reaching out to Microsoft Support or other developer feedback channels to make this request. Thank you.


fix(TabBar): Don't call SelectedIndex setter with the same old value to let it work with bindings

GitHub Issue (If applicable): Closes #562

PR Type
What kind of change does this PR introduce?

What is the current behavior?

What is the new behavior?

PR Checklist
Please check if your PR fulfills the following requirements:

[ ] Tested code with current supported SDKs
[ ] Docs have been added/updated
[ ] Runtime Tests and/or UI Tests for the changes have been added (for bug fixes / features) (if applicable)
[ ] Contains NO breaking changes
[ ] Associated with an issue (GitHub or internal)
[ ] Commits must be following the Conventional Commits specification.

Other information

Internal Issue (If applicable):

@kazo0 @Xiaoy312 Does this sound reasonable?

/azp run


Reword the README

used to attack Ukrainian government institutions https://t.me/CyberArmyofRussia STOP WAR!!!!


children class

not sure if it makes sense to have this as a class with methods for each data source given that taxonomic Ids are unique to each data source. ???


Rename proposal - EddyMotionCorrection -> eddymotion

Something I am always emphasizing is that we are ESTIMATING the eddy and head motion artifacts. The main result is, therefore, not a realigned/eddy-free dataset, but rather, a list of affine transforms.
This perspective is very important because:

Transforms can be combined with other transforms if the user wants to do complicated projections in one interpolation shot.
Transforms can be processed to extract rigid and affine components that can be used down the line for outlier rejection and other processes.
Transforms can be further optimized without introducing smoothing and other deleterious factors - imagine we make a second round of realignment at some point because we find it useful.

Also, I submitted the package to Pypi under the eddymotion name already :D

Okay, I've done it.
@sebastientourbier @dPys @arokem @celprov @josephmje - please note the new name.
on your repos (assuming you called upstream upstream):
git remote set-url upstream git@github.com:nipreps/eddymotion.git

or
git remote set-url upstream https://github.com/nipreps/eddymotion.git

if you are using the https URL.
For your forks, I'd suggest to remove and fork again (except for @dpys, who may want to just fork again just to be sure no code is lost at all).


ERROR: Failed to resolve identifier - weird behaviour

i get good output when parsing :
module fifo (
input reset,
input clk,
input any_push,
input any_pop
);
reg  [1:0] fifo_head [3:0];
reg  [1:0]  fifo_next [3:0];
wire [1:0]  fifo_head4samp [3:0];
genvar fifo_num ;
integer  pntr_num,fifoifo_num;
generate
for (fifo_num=0; fifo_num<4; fifo_num=fifo_num+1) begin:fifo_gen
assign fifo_head4samp[fifo_num] = fifo_next[fifo_head[fifo_num]] ;  /* this is line 16 */
end
endgenerate
endmodule
BUT when adding the following :
always @(posedge clk or negedge reset)
begin
if (!reset) begin
for (pntr_num=0; pntr_num<4; pntr_num=pntr_num+1)
fifo_next[pntr_num] <= {2{1'b0}} ;
end
else if (any_push | any_pop) begin
for (fifoifo_num=0; fifoifo_num<4; fifoifo_num=fifoifo_num+1) begin
fifo_head[fifoifo_num] <= fifo_head4samp[fifoifo_num] ;
end
end
end
endmodule
i get :
ERROR: Failed to resolve identifier \fifo_head for width detection at fifo.v:16!
if i remove the fifo_next assignment the parsing also done successfully
Thanks

Thanks for the report. Fixed by commit 78f65f8.


Created the structure of the landing page and added the logo

I would look for a right hand navigation,  also a single page web,
Hope if @wdevon99 can sketch initials before code it.

Cool!
@wdevon99 can you move it into the root folder so we can use GitHub pages to render it? Github pages just looks for an index.html in the root and will automatically render that.
Also, I think we can update some of the links, e.g. forum could be forum.oosg.org. (I can fix the record to make this work).
Thanks!

Here's a little context on how the pages work.
So, if the public folder is renamed docs it will also work.


Add escape listener for closing full screen view

Related PR #49

@s-yadav I would like to work on this.

Sure go ahead


Make -northstar work on Linux

The argument -northstar can be added to the launch arguments to the base game on Steam, which then launches Northstar if it's installed.
This works by Northstar providing its own wsock32.dll which overwrites the one shipped with Titanfall2 and specifically checks for the -northstar command line argument.
This does however not work on Linux as Wine/Proton uses its own version of wsock32.dll which obviously does not support listening for the -northstar argument.
Therefore to make -northstar work on Linux we need to figure out how to prevent Wine/Proton from overwriting that specific DLL at runtime.

Probably changing the DLL overrides settings in registry for the wineprefix... I wonder if there's some wine hack to make it cleaner

The trick in Windows would be AppInit_DLLs

http://web.archive.org/web/20071229055255/http://support.microsoft.com/kb/197571
http://web.archive.org/web/20100124145108/http://blogs.msdn.com/nickkramer/archive/2006/04/18/577962.aspx
https://docs.microsoft.com/en-us/windows/win32/win7appqual/appinit-dlls-in-windows-7-and-windows-server-2008-r2

But after a glance on WINE source code, it doesn't seem like it implements this, so idk

Going to add my experience here since there was some talk about it in the discord yesterday.
Adding WINEDLLOVERRRIDES="wsock32=n,b" either via WINECFG or launch args does not produce working functionality of -northstar
======================
Proton:<PHONE_NUMBER> TKG-proton-7.12.r1.g0acaed0a
SteamGameId: 1237970
Command: ['link2ea://launchgame/1237970?platform=steam&theme=tf2', '-northstar']
Options: {'nowinedbg', 'dxvkasync', 'useglosmesa', 'logcommandtoprefix', 'nonvapi'}
Kernel: Linux 5.18.9-263-tkg-pds #1 TKG SMP PREEMPT_DYNAMIC Tue, 05 Jul 2022 07:47:16 +0000 x86_64
System WINEDLLOVERRIDES: wsock32=n,b
======================
...
12192.963:07e8:07ec:trace:loaddll:build_module Loaded L"Z:\\home\\tony\\.local\\share\\Steam\\steamapps\\common\\Titanfall2\\bin\\x64_retail\\WSOCK32.dll" at 00007FFFFFA40000: native

Proton loads the native wsock32.dll just fine, but the functionality is not present.

Yet another update. Adding the DLL override along with creating a file called run_northstar.txt in the root directory of Titanfall 2 causes Northstar to be run regardless of having -northstar or -vanilla or simply nothing.
Steps to reproduce:

Have Northstar set up with a working proton or wine version.
add WINEDLLOVERRIDES="wsock32=n,b"
Make sure NorthstarLauncher.exe and Titanfall2.exe are separate and non symlinked executables.
Add run_northstar.txt to the root directory of TF|2
Run the game (Once with -northstar and once without)

@cyrv6737 was that with Steam version of Titanfall2? ^^

WINEDLLOVERRIDES="wsock32=n,b" %command% -northstar

This worked for me (together with run_northstar.txt) :D

WINEDLLOVERRIDES="wsock32=n,b" %command% even works on SteamDeck :D

Given that the run_northstar.txt method works with WINEDLLOVERRIDES but -northstar does not, it's fair to assume that the only reason the latter does not work is due to the command never being passed to the game. If we can figure out the reason for this, then we should be able to get -northstar to work :D

The Linux guide on the has been overhauled to mention a new custom version of Proton for Northstar and run_northstar.txt, simplifying the Linux experience overall ^^
https://r2northstar.gitbook.io/r2northstar-wiki/using-northstar/playing-on-linux

@GeckoEidechse Maybe this issue can be closed now?
Jan figured out the root cause in this PR to upstream Proton, and we now have this patch integrated into NorthstarProton (until it gets upstreamed of course). The only thing that might be an issue is using this outside of Steam with regular Wine, like in Lutris and such.

Good catch, thanks <3

ive added a protonfix workaround in proton-ge that allows this to work without patching steam_helper:
https://github.com/GloriousEggroll/protonfixes/commit/aac5e6267dcc76cf7c5252b6b7b9e32112502588
the current proposed steamhelper patch https://github.com/ValveSoftware/Proton/pull/6555 breaks other games that run batch scripts

updated the steamhelper patch to fix any issues that were brought up.
NorthstarProton is also affected, but its not intended to be used for anything but Northstar so it does not matter.
I've already told this to GE on Discord, but its also worth mentioning here that the protonfix workaround only works if -northstar is the last argument e.g. -novid -northstar.
We should also look into moving away from NorthstarProton, since we've had problems with the current tkg based setup.