text:
add optional figure reference baking injected exercises

Issue: https://github.com/openstax/cnx-recipes/issues/4177

Hi @kswanson33 After Larissa's comment I have reworked the PR to only move the exercise-context if there is only one exercise-question per injected-exercise so this feature will be for now available only for singular part exercises. I have also confirmed it with Larissa. I was also thinking if there will be more exercises questions when there is a exercise-context figure present in some books we perhaps should tag the exercise question with some class, so we will know where to move the exercise-context figure reference but Larissa needs to look into it deeper how the content will look.

repo: openstax/kitchen


text:
Info button/display on add feature search results

This:

But designed to live here:

Re: #6010

I did this! It might use some tweaks, but I think it works pretty well for now.

source: gharchive/issue

repo: openstreetmap/iD

license: ISC

license_type: permissive

license_source: github-api


text:
Allow unglue action on areas

Description
UseCase I need to unglue an area from a road or other area to fix its shape, maybe add another area in between (…).
Right now, I have to select all notes, then uglue, then select them one by one to move them.
I can try to speed up the select with the lasso tool, but in densely mapped areas that does not help.
I can try select + moving them together with the move-shortcut, but since there is not reliable way be sure which node (of a stack of nodes) I select, I end up moving the other border/area/notes in stead of mine, so I have to move them one by one.
Moving them one by one made more tedious since I still don't understand (or cannot remember…) how to reliably specify which note of a stack is selected.
All in all, a unglue-all and them move (shortcut) (and maybe shrink) would make this a lot easier.
Screenshots
No response

The Disconnect operation already works when you select an area: https://github.com/openstreetmap/iD/issues/4245#issuecomment-484986865. Perhaps it was disabled because not enough of the area was visible?
Another thing you can do is to select the area, then hit Ctrl+DownArrow (⌘↓) to recurse down to its nodes, then remove all but the nodes you want to disconnect from the list of selected features, then also select the area again to disconnect just the area at those nodes.

The Disconnect operation already works when you select an area: https://github.com/openstreetmap/iD/issues/4245#issuecomment-484986865.

You are right. No idea why I did not see this…

Ctrl+DownArrow (⌘↓)

Thanks, that is great as well. Will finally need to remember that shortcut!
Thanks for the help => Closed.


text:
Empty node icon now missing

Yet area has an empty node icon...

(related to earlier issue);

The version on osm.org just got updated and the new bike parking icon now shows up:

( https://github.com/openstreetmap/iD/issues/9136#issuecomment-1150084562 )

interesting… it works for me

Can you please explain how exactly you managed to trigger the bug?

Clearing the cache fixed it.
Browser: Chrome

@tyrasd I just ran into another issue, was about to submit it but saw your reply. Sorry for the multiple edits, but I've changed my top post now to describe the issue correctly.

Also, empty ways now look like this (white-on-white):

Summary;

Expected behaviour: Area should show an empty square, not a point icon. node part of area or way shoud show a point icon.

this is how it is supposed to look like, isn't it?

Mostly it makes sense, but you should be able to see at least the nodes (black casing). If you want to display an empty line, you could do the same and give it black casing

Ah, the missing icon is for vertex nodes. Sorry, I somehow didn't get that info in your first post.
This regression was introduced in bd1836fd0cf53254ed88352eb69a78da51092692.


text:
New man_made=utility_pole preset

Dear maintainers
Following the recent approval of the man_made utility poles proposal, a new preset to use man_made=utility_pole with the following combinations could be useful
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dutility_pole

utility=* The purpose for which the pole was design or installed
operator=* Name of the company that operates the pole
material=* The material composing the pole
line_attachment=* Attachment mean for lines connected to that pole
line_management=* Particular topology situations around the pole
ref=* The reference of the pole as read on ground

A similar icon of one used for power=pole can be used.
A few validation rules also applies

utility=* should have only one value, ;-lists are discouraged
power=pole remains the standard to map power poles. when utility=power, man_made=utility_pole should be replaced by power=pole

Let me know if you consider including it in the iD tagging schema
All the best

utility=* should have only one value, ;-lists are discouraged

I don't think that's actually a thing. Even if the Wiki says it is. As there's plenty of uses of the tag with multiple values and utility poles IRL often times aren't confined to a single type of utility. In the meantime, I'd be interested to know where the sentence about it in the article came from and why it was added.

As there's plenty of uses of the tag with multiple values and utility poles IRL often times aren't confined to a single type of utility

That's not the meaning of utility=*
Despite a given pole can carry many different stuff, it was designed for a main purpose. Side business comes... aside.
A power pole, operated by the power system operator, carrying telephone wires remains a power pole.
Furthermore, some features supported by such a pole don't refer to utilities (surveillance camera, traffic signs, advertisement...). Wiki also gives an extensive list of strategies to get what a pole actually supports
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dutility_pole#Examples

In the meantime, I'd be interested to know where the sentence about it in the article came from and why it was added.

Reviewed proposal can be found here: https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_poles_proposal

Despite a given pole can carry many different stuff, it was designed for a main purpose

Cool, I didn't ask what your personal opinion was though. In the meantime, where does anything besides the Wiki article say "it was designed for a main purpose?" Just repeating what the article says doesn't answer my question of where it came from.

Reviewed proposal can be found here

I'm talking about the utility key, not man_made=utility_pole. Their different tags and don't have anything to do with each other. Except that utility=* is used on utility poles sometimes, among many other things.
That said, from what I can tell neither of the proposals say that utility=* should only be to tag a single value. All Proposed_features/Utility_markers_proposal says is that utility=* is used to "state at which activity they refer to" and the last time I checked that can be multiple things. The proposal for man_made=utility_pole just specify either. So again, where besides the utility article does the idea that it's only supposed to be a single value come from?

Cool, I didn't ask what your personal opinion was though. In the meantime, where does anything besides the Wiki article say "it was designed for a main purpose?"

It's part of several state of the art data models.
At least in France, you can find such similar tagging in gov's official documentation of utility networks data standard
http://cnig.gouv.fr/?page_id=17429
http://cnig.gouv.fr/wp-content/uploads/2019/11/CNIG_STAR-DT_v1.0.pdf
Page 29 you find the NatureReseauPCRSType attribute, with a multiplicity of 1 which is equivalent to expect only one value for utility=* in OSM.
It has to be said we don't plan to import any data from anywhere. It's only about equivalency of data models here.

Their different tags and don't have anything to do with each other.

I disagree: tags are combined with usage guidelines. It was explicitly reviewed to use utility with a single value for utility poles.
It wasn't stated so explicitly for markers proposal (which introduced utility=* as well) but it should had been.
You barely find a single marker involved in several utilities, because several different companies are responsible of them and they will install their own marker, even in very close spots.

That said, from what I can tell neither of the proposals say that utility=* should only be to tag a single value

I may not get you well on this particular point.
https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_poles_proposal#Proposale
utility=* will be combined with it to give the main or original purpose of the pole. This key is expected with one unique value for a given pole, according to rationale downside.
Isn't this clear?

It's part of several state of the art data models.

That I assume have nothing to do with OSM. It should be obvious that how the French government and OSM tag things might converge in some places and that the standards in OSM override the later. Unless of course you do a proposal and get community buy in to adopt it. Which it doesn't seem like you have. Otherwise, we probably wouldn't be having this discussion right now.

It has to be said we don't plan to import any data from anywhere. It's only about equivalency of data models here.

OSM isn't suppose to be a 1/1 equivalent of government maps. Although, there's no reason you can't make it that way for utility poles if it's your personal preference to do so. But that's completely different from expecting there to be a preset that forces other people, who aren't mapping wrong by not including the operator, into it.

t wasn't stated so explicitly for markers proposal (which introduced utility=* as well) but it should had been.

Maybe it should have been, but the important thing was it wasn't. Although, I don't think it should have been just because the French governments GIS department does something a certain way. Since tags are suppose to be universally usable and I can guarantee places outside France don't do it how they do.

I may not get you well on this particular point.

Sure, I get that point. But like you say it's not in the original proposal and I'm not sure how much a proposal for an unrelated tag can override it. Like just because there's a proposal for something like shop=whatever that includes mention of another approved tag, it doesn't mean that the shop=whatever proposal can totally reinvent the other tagging scheme that it mentions. Let alone restrict it's usage. Otherwise, your overruling the original proposal/consensus and likely without involving the same people.  If there was a specific proposal to modify the utility tag to only use one value I'd be cool with that though.
Also, the sentence you quoted is contradicted further down where it says "A pole can support several networks and different utilities." If a pole supports several utilities, then we should be able to tag that. There's way to tell that "some side business come afterwards" either. Nor should it matter.

This is definitely not a place to challenge what was previously voted, on which a consensus has been reached.
Utility poles proposal clearly define combination guidelines between man_made=utility_pole and utility=. It doesn't redefine utility= at all.
Current usage shows it's pretty always used with a single value.
https://taginfo.openstreetmap.org/keys/utility#values

just because the French governments GIS department does something a certain way

I'm not happy with the way you turn things. I'll stop providing explanations as they are used against valuable, discussed and reviewed work done by several contributors.

If a pole supports several utilities, then we should be able to tag that

Can you point me a proper resource stating this apart of your personal opinion please?

Utility poles proposal clearly define combination guidelines between man_made=utility_pole and utility=. It doesn't redefine utility= at all.

If the original utility=* proposal didn't specify that it should only have one value, but the proposal for man_made=utility_pole does then how is that not redefining how the utility=* tag can be used?

Current usage shows it's pretty always used with a single value.

There's a difference between "pretty always" and "always." I don't really care what the current usage is anyway. I care about what the original proposal said about how to use the tag or not. For all I know there's a small amount of multiple values because someone with a personal opinion that thought they were wrong did an un-discussed mass edit.

I'm not happy with the way you turn things. I'll stop providing explanations as they are used against valuable, discussed and reviewed work done by several contributors.

I don't know why your being defensive. It's just a fact that OSM and local governments will have different ways of tagging things.   Every GIS department/website/whatever serves different needs and does things differently. It's just reality and it's not an insult to the French government to state there isn't going to be a 1/1 fit between how they do things and OSM.

Can you point me a proper resource stating this apart of your personal opinion please?

I'm sure your aware of the whole "Ground truth" thing. If the "ground truth" of a utility pole is that it serves multiple utilities then people should "Map what's on the ground" by tagging it that way.

but the proposal for man_made=utility_pole does then how is that not redefining how the utility=* tag can be used?

It brings precision on how to use it in this particular context.
Many proposals involve existing generic tags like location=*, usage=*... keys and sometimes complete them with additional values or so. It didn't cause any harm to existing practices as far as I remember.
People involved in RFC or voting are fully aware of that. How would it be possible to define keys like location=* with a single proposal to cover all possible situations on a large diversity of knowledge ?

I care about what the original proposal said about how to use the tag or not

Experience, tests, admit to be wrong and lessons learnt are more important than what wasn't part of a proposal written with less knowledge in mind, aren't you?

I don't know why your being defensive. It's just a fact that OSM and local governments will have different ways of tagging things.

Because the point isn't to enforce local SIG practices in OSM but to get inspired by what is currently working elsewhere.

If the "ground truth" of a utility pole is that it serves multiple utilities then people should "Map what's on the ground" by tagging it that way.

Tagging isn't the only informational mean in OSM. Topology is a good one as well.
It is well described how this should be achieved in a more efficient way than tagging only: https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dutility_pole#Logical_link_between_poles_and_supported_features
Practical example: a power pole (operated by the power distribution operator) supports a minor power line, a fibre to the home cable and a surveillance camera.
You may expect utility=power;telecom;surveillance

First problem: surveillance isn't an utility, intending to describe all features supported by the pole with utility=* is vain.
Second problem: Adding a telecom line on a pole designed for power doesn't make it a telecom pole
Finally, utility=power remains the only valid option here.

There is a difference between what the pole actually is and what it supports. utility=* only focuses on the first.

Many proposals involve existing generic tags like location=, usage=... keys and sometimes complete them with additional values or so. It didn't cause any harm to existing practices as far as I remember.

Sure, but your assertion from the start of this has been that the utility=* was designed for a single purpose. Not that there is just an exception made for utility poles. Nor is that how the utility Wiki article edited to make it sound. From what I can tell the standard was changed in the utility_pole proposal and then post hawk applied to the utility tag more general. Not just in cases of utility poles. Which is why I have a problem.
I likely wouldn't care if the utility pole proposal wasn't applied more broadly though and just stuck to utility poles where it was intended. No one tagging pipelines, substations, or any other utility besides utility poles had a say in it being applied to their use case though.

Because the point isn't to enforce local SIG practices in OSM but to get inspired by what is currently working elsewhere.

I disagree that presets equate to inspiration. I think your reading to much into their effect at the cost of other, probably better, avenues to get what you want done. That's all.

You may expect utility=power;telecom;surveillance

I wouldn't expect utility=surveillance for the reason you gave. I don't think there's a clear difference between what a pole was designed for and what it supports either. It would be weird to continue tagging a utility pole as utility=power if it is converted to only carry telecommunications wires just because of what it's original use was.
If you want a better example, there's utility poles in my area that both carry power and serve as street_lighting. So in that case should I revert someone if they add utility=power;street_lighting just because the pole was originally made for transferring power?

From what I can tell the standard was changed in the utility_pole proposal and then post hawk applied to the utility tag more general. Not just in cases of utility poles.

It indeed went beyond the extent I wanted to give. I've adjusted the guidelines and removed the need of a single value in utility documentation.

I disagree that presets equate to inspiration.

It's not about presets but tagging model there. Existing practices can inspire us to propose new tags or adapt existing ones, nothing more.
It sounds different to me.

I don't think there's a clear difference between what a pole was designed for and what it supports either

A pole may last ~50 years and usage may evolve since its installation. We roll out fibre to the homes while it wasn't even an idea when electricity came years ago.

It would be weird to continue tagging a utility pole as utility=power if it is converted to only carry telecommunications wires just because of what it's original use was.

In such situations it depends if the pole remains a power operator asset or being sold to another company instead. Local signage will change, local policy could also be adapted. It's anyway a mean to raise quality error and encourage to check what happen in details because it's unusual (and local practices influence a lot)

So in that case should I revert someone if they add utility=power;street_lighting just because the pole was originally made for transferring power?

yes
It's a power pole supporting a street lamp, not the opposite.

Personally, I'd like to think the power infrastructure and street lighting infrastructure mappers can coexist.

They actually coexist since you'll find a power pole member of a power (minor) line and completed with highway=street_lamp.
This could finally change if the power line is removed, the street lamp will remain and utility will change to street_lighting.

It indeed went beyond the extent I wanted to give. I've adjusted the guidelines and removed the need of a single value in utility documentation.

Thanks. I appreciate your willingness to listen to feedback and adjust things.

Existing practices can inspire us to propose new tags or adapt existing ones, nothing more.

True. I don't disagree.

hey actually coexist since you'll find a power pole member of a power (minor) line and completed with highway=street_lamp.

I mostly agree with that. Except I think the existence of a physical street lamp is different from street lighting infrastructure more generally. Which, if I am reading the Wiki correctly, is what the utility tag is meant to convey. I don't know how things work in France, but in a lot of countries street lighting utilities are different departments then general power is.
Semi-related, but likely off topic. where I live power poles are owned and maintained by PG&E, but leased by them to the local governments electric utility for their power lines to be ran on. So the whole thing is pretty convoluted. I don't know how it would be reflected in tagging. I guess different operators for the poles and powerlines or something. A lot of the power poles have multiple reference numbers (PG&E, local utility, closest address, Etc. Etc.). I usually just leave all of them out when I'm mapping except the local utilities 🤷♂

I don't know how things work in France, but in a lot of countries street lighting utilities are different departments then general power is.

Exactly and that's why street lightly is mostly out of power=* key in OSM.

I don't know how it would be reflected in tagging. I guess different operators for the poles and powerlines or something. A lot of the power poles have multiple reference numbers (PG&E, local utility, closest address, Etc. Etc.)

Interesting situation
If the poles are actually rented, PG&E remains the operator on the power=pole feature and then lines could have different operator=* on their own.
In France we have different ref:FR:* keys to store reference which allows to combine several on the same object
For instance ref:FR:RTE (transmission), ref:FR:gdo (distribution).
It's sometimes better to only map geometries and leave operational knowledge for further contribution when it will have been solved.

The preset has been added.

Hello @Dimitar5555
What was the PR related to this preset please?

You are right. I though that all of the fields were added. I've created a PR which will resolve this issue.

So nice!
I'll have a glance at it shortly

repo: openstreetmap/id-tagging-schema


text:
JVM Deadlock

At random times we get deadlocks. The jstack is showing this:
"pool-15-thread-4":
waiting to lock Monitor@0x00007fd4cc0bc4b8 (Object@0x000000044b81fc90, a mobi/coolsigns/sms/proxy/service/gateway/embedded/smpp/session/SMPPSessionCustom),
which is held by "PDUReaderWorker: mobi.coolsigns.sms.proxy.service.gateway.embedded.smpp.session.SMPPSessionCustom@454fd63"
"PDUReaderWorker: mobi.coolsigns.sms.proxy.service.gateway.embedded.smpp.session.SMPPSessionCustom@454fd63":
waiting for ownable synchronizer 0x000000042de26f70, (a java/util/concurrent/locks/ReentrantLock$NonfairSync),
which is held by "pool-15-thread-4"
The SMPPSessionCustom is nothing fancy just an extension of the original Class that returns the SMPPResultResp and not only the Id.
`public class SMPPSessionCustom extends SMPPSession {
private static final AtomicReference currentTime = new AtomicReference<>(System.currentTimeMillis());
private final ConnectionProperties connectionProperties;
private final int timeout;
private final long id;

public SMPPSessionCustom(ConnectionProperties connectionProperties) {
	super();
	this.connectionProperties = connectionProperties;
	this.timeout = this.connectionProperties.get(ConnectionConstants.OPERATOR_SUMBIT_SM_TIMEOUT, 35000);
	this.id = currentTime.accumulateAndGet(System.currentTimeMillis(),
			(prev, next) -> next > prev ? next : prev + 1);
}

public SMPPSessionCustom(PDUSender pduSender, PDUReader pduReader, ConnectionFactory connFactory,
		ConnectionProperties connectionProperties) {
	super(pduSender, pduReader, connFactory);
	this.connectionProperties = connectionProperties;
	this.timeout = this.connectionProperties.get(ConnectionConstants.OPERATOR_SUMBIT_SM_TIMEOUT, 35000);
	this.id = currentTime.accumulateAndGet(System.currentTimeMillis(),
			(prev, next) -> next > prev ? next : prev + 1);
}

public SMPPSessionCustom(String host, int port, BindParameter bindParam, PDUSender pduSender, PDUReader pduReader,
		ConnectionFactory connFactory, ConnectionProperties connectionProperties) throws IOException {
	super(host, port, bindParam, pduSender, pduReader, connFactory);
	this.connectionProperties = connectionProperties;
	this.timeout = this.connectionProperties.get(ConnectionConstants.OPERATOR_SUMBIT_SM_TIMEOUT, 35000);
	this.id = currentTime.accumulateAndGet(System.currentTimeMillis(),
			(prev, next) -> next > prev ? next : prev + 1);

}

public SMPPSessionCustom(String host, int port, BindParameter bindParam, ConnectionProperties connectionProperties)
		throws IOException {
	super(host, port, bindParam);
	this.connectionProperties = connectionProperties;
	this.timeout = this.connectionProperties.get(ConnectionConstants.OPERATOR_SUMBIT_SM_TIMEOUT, 35000);
	this.id = currentTime.accumulateAndGet(System.currentTimeMillis(),
			(prev, next) -> next > prev ? next : prev + 1);

}

public SubmitSmResp submitShortMessageGetResp(String serviceType, TypeOfNumber sourceAddrTon,
		NumberingPlanIndicator sourceAddrNpi, String sourceAddr, TypeOfNumber destAddrTon,
		NumberingPlanIndicator destAddrNpi, String destinationAddr, ESMClass esmClass, byte protocolId,
		byte priorityFlag, String scheduleDeliveryTime, String validityPeriod,
		RegisteredDelivery registeredDelivery, byte replaceIfPresentFlag, DataCoding dataCoding,
		byte smDefaultMsgId, byte[] shortMessage, OptionalParameter... optionalParameters) throws PDUException,
		ResponseTimeoutException, InvalidResponseException, NegativeResponseException, IOException {

	ensureTransmittable("submitShortMessage");

	SubmitSmCommandTask submitSmTask = new SubmitSmCommandTask(pduSender(), serviceType, sourceAddrTon,
			sourceAddrNpi, sourceAddr, destAddrTon, destAddrNpi, destinationAddr, esmClass, protocolId,
			priorityFlag, scheduleDeliveryTime, validityPeriod, registeredDelivery, replaceIfPresentFlag,
			dataCoding, smDefaultMsgId, shortMessage, optionalParameters);

	SubmitSmResp resp = (SubmitSmResp) executeSendCommand(submitSmTask, timeout);
	return resp;
}

public long getId() {
	return id;
}

}`

It affected both the last and the previous releases of JSMPP. Have not tried with previous ones lately. When I was using the 0.2.2 did not have this but i have not confirmed lately.

I created a sample project, using this SMPPSessionCustom code, in https://github.com/pmoerenhout/jsmpp-sample-spring-boot. It creates a server and concurrent connect clients to it, sending concurrent messages in the session. I could not reproduce this deadlock. Could you provide some more info?

Hi,
I should have given more context. We have faced the problem only with one SMSC. We are having 200 TPS allowed there and each message we are sending to the SMSC it get special handling which is very time consuming. As a result a lot of timeouts take place, even for enquire links, and as a result we are having a lot of diconnections (more than 4 per hour).
Based on the code of the example we are doing auto reconnects.
At some point in random times we are seeing outgoing on the account being frozen and the JStack is giving this dead lock indication. I suspect it has to do with the constant reconnects OR with the fact that timeouts are set very high (over 36 seconds) due to the traffic the other end has.
Furthermore, the SMSC in case that they cannot process the SMS for some reason (e.g. the msisdn is purged from their subscriber list) they will throw a custom error code (which the library is handling as NegativeResponseException). We are talking about millions of cases like that.
Again I am not sure if the above are relevant to the error but I submit them for greater context.

Thanks, I will try to simulate this scenario. Can you show how the reconnect logic is implemented ?

private void reconnectAfter(final long timeInMillis) {

	final Runnable r = new Runnable() {
		int attempt = 0;
		int sleep = 1;

		public void run() {

			try {
				rlock.lockInterruptibly();
				sessionBounder.acquire();
				if (activeSessions.isMaximumConnectedReached(numberOfSessions)) {
					CONN_LOGGER.warn("ActiveSessions [{}] have a size [{}] so no more retries", operatorName, activeSessions.size());
					return;
				} else {
					CONN_LOGGER.info("Reconnecting attempt {} for operator [{}] with current active sessions [{}]...", ++attempt,
							operatorName, activeSessions.size());
					final SMPPSessionCustom session = createNewSmppSession();

					if (session.getSessionState().isBound()) {
						activeSessions.add(session);
						CONN_LOGGER.info("Reconnected session [{}] to [{}:{}] for operator [{}]. Active Sessions [{}]",
								session.getSessionId(), host, port, operatorName, activeSessions.size());
					}

				}
			} catch (IOException e) {
				CONN_LOGGER.error(
						"Attempt {} failed opening connection and bind to {}:{} for operator [{}]. The operator has [{}] active sessions. Error {}",
						attempt, host, port, operatorName, activeSessions.size(), e.getMessage());

				if (sleep < 512) {
					sleep *= 2;
				} else {
					sleep = 1;
				}
				if (!isNormalShutdown) {
					CONN_LOGGER.info("Next reconnect attempt in {} seconds for operator [{}]", sleep, operatorName);
					scheduler.schedule(this, sleep, TimeUnit.SECONDS);
				}

			} catch (InterruptedException e) {
				Thread.currentThread().interrupt();
			} finally {
				sessionBounder.release();
				rlock.unlock();
			}
		}
	};
	scheduler.schedule(r, 1, TimeUnit.SECONDS);

}

private SMPPSessionCustom createNewSmppSession() throws IOException {
	final SMPPSessionCustom tmpSession = new SMPPSessionCustom(connectionProperties);
	tmpSession.addSessionStateListener(new SessionStateListenerImpl(5000L));
	final MessageReceiverListener msgReceiverListener = ctx.getBean(MessageReceiverListener.class, operatorName);
	tmpSession.setMessageReceiverListener(msgReceiverListener);
	int timer = connectionProperties.get(ConnectionConstants.OPERATOR_CONNECTION_ENQUIRELINK_TIMER, 10000);
	long timeout = connectionProperties.get(ConnectionConstants.OPERATOR_CONNECTION_ENQUIRELINK_TIMER_TIMEOUT, 6000);
	tmpSession.setEnquireLinkTimer(timer);
	tmpSession.setTransactionTimer(timeout);
	tmpSession.connectAndBind(host, port, bindParameters, 5000);
	return tmpSession;
}

@Override
public boolean isReady() throws InterruptedException {
	return activeSessions.size() > 0;
}

/**
 * Private class SessionStateListenerImpl to make sure automatic
 * reconnection takes place upon connection loss.
 *
 */
private class SessionStateListenerImpl implements SessionStateListener {

	private final long reconnectInterval;

	public SessionStateListenerImpl(final long reconnectInterval) {
		this.reconnectInterval = reconnectInterval;
	}

	@Override
	public void onStateChange(SessionState newState, SessionState oldState, Session source) {
		if (newState.equals(SessionState.CLOSED) && !isNormalShutdown) {

			try {
				rlock.lockInterruptibly();
			} catch (InterruptedException e) {

			}
			try {
				activeSessions.remove(source);
				CONN_LOGGER.debug("Session closed for operator [{}]", operatorName);

			} finally {
				rlock.unlock();
			}
			CONN_LOGGER.debug("Active connections left {} for operator [{}]", activeSessions.size(), operatorName);
			reconnectAfter(reconnectInterval);
			source = null;
		}
	}
}

The ActiveSessions class is:
public class ActiveSMPPSessions {

private final static Logger LOGGER = LoggerFactory.getLogger(ActiveSMPPSessions.class);

private final List<SMPPSessionCustom> activeSessions = new LinkedList<>();

private Iterator<SMPPSessionCustom> elements = null;

public synchronized boolean add(final Session session) {
	boolean b = false;
	b = activeSessions.add((SMPPSessionCustom) session);
	createCycle();
	notifyAll();
	return b;
}

public synchronized boolean remove(final Session session) {
	boolean b = false;
	b = activeSessions.remove(session);
	createCycle();
	return b;
}

public synchronized int size() {
	return activeSessions.size();
}

private void createCycle() {
	elements = Iterables.cycle(activeSessions).iterator();
}

private void destroyCycle() {
	elements = null;
}

public synchronized SMPPSessionCustom getNext() {
	return elements.next();
}

public synchronized int indexOf(SMPPSessionCustom session) {
	return activeSessions.indexOf(session);
}

public synchronized boolean isAnyBound() {
	return activeSessions.size() > 0;
}

public synchronized boolean waitAnyBound() throws InterruptedException {
	while (!isAnyBound())
		wait();
	return true;
}

public List<SMPPSessionCustom> getSessions() {
	return new LinkedList<>(activeSessions);
}

public synchronized void unbindAndClose() {
	destroyCycle();
	for (final SMPPSessionCustom s : activeSessions) {
		try {
			LOGGER.info("Unbinding and closing of activeSession {}", activeSessions.indexOf(s));
			s.unbindAndClose();
		} catch (Exception e) {
			LOGGER.error("Error unbing session! {}", e.getMessage());
			LOGGER.debug("{}", e);
		}
	}
	activeSessions.clear();
}

public synchronized boolean isMaximumConnectedReached(int numberOfSessions) {
	return this.activeSessions.size() >= numberOfSessions;
}
}

I should also mention that the SMS are submitted to a threadpool but because each SubmitSM might take up to 36 seconds for the SMSC to respond and in order to achieve 200 TPS I was forced to create 1400 threads (in lack of async capabilities) which I know it can be problematic but had no better solution to it.
The actual sending is done through this callable:
private class SenderTask implements Callable<SubmitSMResult> {

	private final ShortMessage mt;

	public SenderTask(final ShortMessage mt) {
		this.mt = mt;
	}

	@Override
	public SubmitSMResult call()
			throws PDUException, ResponseTimeoutException, InvalidResponseException, NegativeResponseException, IOException {
		SubmitSMResult sr = null;

		JSMPPMtDTO jsDTO = new JSMPPMtDTO(mt, defaultServiceType, ommitPlusSign);

		scheduleDeliveryTime = relative.format(Date.from(LocalDateTime.now(zoneId).plusSeconds(1).atZone(zoneId).toInstant()));
		validityPeriod = null; // relative.format(Date.from(LocalDateTime.now(zoneId).plusDays(1).atZone(zoneId).toInstant()));
		final SMPPSessionCustom session = activeSessions.getNext();
		LOGGER.trace(
				"Bind Parameters: [ bindType [{}], systemId [{}], password [{}], systemType [{}], addrTon [{}], addrNpi [{}], addressRange [{}]",
				bindType, systemId, password, systemType, addrTon.ordinal(), addrNpi.ordinal(), addressRange);
		LOGGER.trace(
				"Sms [ serviceType: [{}], srcTon: [{}], srcNpi: [{}], sourceAddr: [{}], destAddrTon: [{}], destAddrNpi: [{}], "
						+ "destination: [{}], esmClass: [{}], protocolId: [{}], priorityFlg: [{}], scheduleDeliveryTime: [{}], validityPeriod: [{}],"
						+ " registeredDelivery: [{}], replaceIfPresentFlag: [{}], dataCoding: [{}], smDefaultMsgId: [{}], body: [{}] ].",
				jsDTO.getServiceType(), srcTon.ordinal(), srcNpi.ordinal(), jsDTO.getSender(), destAddrTon.ordinal(),
				destAddrNpi.ordinal(), jsDTO.getDestination(), esmClass, protocolId, priorityFlag, scheduleDeliveryTime, validityPeriod,
				jsDTO.getRegisteredDelivery().value(), replaceIfPresentFlag, jsDTO.getDataCoding(), smDefaultMsgId, jsDTO.getBody());

		final SubmitSmResp submitSmResp = session.submitShortMessageGetResp(jsDTO.getServiceType(), srcTon, srcNpi, jsDTO.getSender(),
				destAddrTon, destAddrNpi, jsDTO.getDestination(), esmClass, protocolId, priorityFlag, scheduleDeliveryTime,
				validityPeriod, jsDTO.getRegisteredDelivery(), replaceIfPresentFlag, jsDTO.getDataCoding(), smDefaultMsgId,
				jsDTO.getBody());

		sr = new SubmitSMResult(mt, submitSmResp);

		return sr;
	}

And the result is handled by Guava's registered callbacks on the Listening service the callable is run by.

I just released 2.3.4 where I did remove a synchronized statement when closing. Could you test with this version?

Thank you for your help. Due to the severity of this issue (freezing and most of the times during the night) I switched to cloudhopper. However if I get the chance I will try to test it at a later stage.

authors: alexkonti pmoerenhout

repo: opentelecoms-org/jsmpp

license_source: bigquery


text:
[utils] add option to use external heap

This PR introduces a new API call:
otHeapSetCAllocFree

The API is available to the application from instance.h header and is enabled when EXTERNAL_HEAP common switch is set.
The call must be invoked before the OpenThread instance is initialized.
This allows the OpenThread to use an external heap for allocation, for example from FreeRTOS.

I found the Heap is only used in the following places:
src/core/common/instance.hpp:259:    Utils::Heap &GetHeap(void) { return mHeap; }
src/core/crypto/mbedtls.cpp:56:    return Instance::Get().GetHeap().CAlloc(aCount, aSize);
src/core/crypto/mbedtls.cpp:61:    Instance::Get().GetHeap().Free(aPointer);
src/core/meshcop/border_agent.cpp:278:    instance.GetHeap().Free(&forwardContext);
src/core/meshcop/border_agent.cpp:578:    forwardContext = static_cast<ForwardContext *>(GetInstance().GetHeap().CAlloc(1, sizeof(ForwardContext)));
src/core/meshcop/border_agent.cpp:612:            GetInstance().GetHeap().Free(forwardContext);

Is it possible to support external heap by macros? Such as
// src/core/utils/heap.hpp
#if !OPENTHREAD_CONFIG_EXTERNAL_HEAP_ENABLE
#define otCAlloc(aInstance, aCount, aSize) static_cast<Instance*>(aInstance)->GetHeap().CAlloc(aCount, aSize)
#define otFree(aInstance, aPointer) static_cast<Instance*>(aInstance)->GetHeap().Free(aPointer)
#endif

The the platform can replace the allocators. On POSIX, it is possible to do:
#define otCAlloc(aInstance, aCount, aSize) calloc(aCount, aSize)
#define otFree(aInstance, aPointer) free(aPointer)

Thoughts?

The difference with calloc and free is that those functions are standard library calls.
In embedded systems we can't be sure whether the user wants to use FreeRTOS, Zephyr or any other system that provides its own heap implementation. That's why I think it would be more suitable to allow the user to set the allocators in the runtime, instead of having them change platform source file, or providing a platform specific API that would have the same effect.

@e-rk Sounds good to me! Is it possible to implement the external heap API in src/core/api/heap.c and define in include/openthread/heap.h?

@bukepo Thanks for your suggestions.
There are various things I had to consider when I implemented the external heap capability.
The heap must be already available before calling the otInstanceInitSingle function. The reason is that the mbedTLS already makes heap allocations inside the instance's constructor. That is why I had to statically allocate the pointers to otCAllocFn otFreeFn functions. I also wanted to allow the OpenThread to initialize/reinitialize its own internal heap object (if enabled) when it needs to and without introducing additional mechanism aside from the already used Heap constructor.
I considered creating a base Heap object, from which an InternalHeap and ExternalHeap would derive. The ExternalHeap would then refer to statically allocated otCAllocFn and otFreeFn and the InternalHeap would reside inside the instance. However it would require virtual method calls if the heap was to be retrieved using the GetHeap method, which is something I wanted to avoid. To avoid using the virtual methods here I would have to #if #else the GetHeap method to return the correct type, but it would require the heap users to know of the two implementations.
That is why I thought that making the Heap class an interface between the statically allocated internal/external heap implementations was the way to go.
What are your thoughts though?

@bukepo I have pushed the commit from your branch with changed commit messages and I moved some things around on top of it.

@abtink If you go through the history of this PR, it was originally implemented in class way. After discussions, we found implementing this way looks cleaner. Utils::Heap is a utility class for managing a block of memory, I tend to keep it as is. Besides, heap user only needs two functions, I don't think it's necessary to interface at Utils:Heap level. Thoughts?

Thanks @bukepo. I looked at the history.
Here is my suggestion (which is somewhat different from what was done originally):

We keep a single Utils:Heap class in utils/heap.hpp with its implementation in utils/heap.cpp.
The Heap class defines a common set of APIs and bunch of configuration specific APIs.

class Heap
{
   // Common APIs
    Heap(void);
    void *CAlloc(size_t aCount, size_t aSize);
    void Free(void *aPointer);

    // Config specific APIs
#if !OPENTHREAD_CONFIG_EXTERNAL_HEAP_ENABLE   // internal
    bool IsClean(void) const;
    size_t GetCapacity(void) const { return kFirstBlockSize; }
    //...
#else  // Any external-specific APIs

#endif
};

Within core any module can use the Heap class common APIs.

If a module wants a config specific API it needs to add the related #if checks when it uses it.

In the Heap class implementation we hide which flavor is being implemented (internal/external).

Another suggestion (which I saw being discussed above) is about the external model and how to provide the free and calloc. I think instead of using function pointers, we should delegate this to platform:

We define two new (optional) platform APIs in a new platform header file : include/openthread/platform/heap.h void *otPlatHeapCAlloc(size_t aCount, size_t aSzie);
 void otPlatHeapFree(void *aPointer);

These platform APIs are used by Heap class implementation and only when EXTERNAL_HEAP config is enabled.
This moves the definition to platform layer which seems to be a better fit for these APIs (make sense for platform/systems to provide such functionality). Also we won't need to provide a public OT API to set these as fun pointers and also no need to check/assert that the fn pointers are not NULL before using them.

Overall, I feel this model is simpler and cleaner.
Thoughts?

@abtink I think the first topic is where we define the interface to dynamic allocating memory. The second is how user provide the external allocator.
For topic 2, @e-rk described one requirement is to set allocator at runtime instead of at build time(see in the comment). mbedTLS has similar design: https://github.com/openthread/openthread/blob/master/src/core/crypto/mbedtls.cpp#L71. I think it's possible for us to support both ways, static and runtime.
For topic 1, as we have multiple ways to support external Heap, internal, static, runtime and we even have an option to support multiple OpenThread instances(i.e. Utils::Heap is not singleton), so I tend to keep Utils::Heap a simple utility module. And define unified memory allocating APIs in upper layers, maybe in Instance or src/core/api/heap_api. Thoughts?

Thank you @bukepo for providing an explanation.
I have pushed the changes @abtink suggested about moving static definitions to instance.cpp.

source: gharchive/pull-request

authors: abtink bukepo e-rk

repo: openthread/openthread


text:
✨ [Feature]: 希望 TinyPro 增加多页签模式

What problem does this feature solve
What problem does this feature solve
使用TinyPro构建管理系统，用户在使用管理系统时候，操作表单数据时，往往需要查看相关联的业务数据，查看或者核对后，再返回当前页面填入和编辑数据，没有多页签，管理系统非常难使用，尤其涉及财务数据，数据是不能错的，用户只能记录到纸上，把需要的数据一一准备好，然后再打开要操作的页面进行处理。一般管理类系统要求必须支持多页签，没有多页签没法使用。
What does the proposed API look like
1、每点击一个菜单，也多页签位置多一个对应页面；
2、弹出对话框应该在页面内，切换多页签不影响对话框，切换回来时，页签内对话框所填写的内容保持原样。
3、页面内所有的状态在多页签切换时保持原样，选择的查询条件、翻页、选中的记录等，在页签切换回来时，均保持原样。
What does the proposed API look like
详细可以参考：https://github.com/opentiny/tiny-vue/issues/609

#149 #159 #139

authors: GaoNeng-wWw kagol

repo: opentiny/tiny-cli

license: MIT


text:
Update index.html

Added our company support towards this development effort.

@flavius-dinu Can you please review this change and accept. Thanks, Yogen

Added in https://github.com/opentofu/manifesto/pull/1158

authors: flavius-dinu jntupal

repo: opentofu/manifesto


text:
Segfault when shutting down openresty

I'm using:

Debian stretch
openresty 1.13.6.2
nginx-opentracing 0.8.0
lua-bridge-tracer 0.1.0 or master

I added the nginx-opentracing module to openresty and installed lua-bridge-tracer. I'm able to report spans from within Lua, but when shutting down openresty (by sending SIGTERM), I hit a segfault.
The backtrace looks like this:
$ gdb $(which openresty) core
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/openresty/bin/openresty...done.

warning: core file may not match specified executable file.
[New LWP 12491]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `nginx: worker process                                                  '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f5b16d0765a in std::_Sp_counted_ptr<opentracing::v2::Span*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x55ac4223c7d0)
    at /usr/include/c++/6/bits/shared_ptr_base.h:372
372           { delete _M_ptr; }
(gdb) bt
#0  0x00007f5b16d0765a in std::_Sp_counted_ptr<opentracing::v2::Span*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x55ac4223c7d0)
    at /usr/include/c++/6/bits/shared_ptr_base.h:372
#1  0x000055ac401aebb2 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x55ac4223c7d0)
    at /usr/include/c++/6/bits/shared_ptr_base.h:150
#2  0x00007f5b16d00b8f in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x55ac421e3b08, __in_chrg=<optimized out>)
    at /usr/include/c++/6/bits/shared_ptr_base.h:662
#3  0x00007f5b16d038e6 in std::__shared_ptr<opentracing::v2::Span, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x55ac421e3b00,
    __in_chrg=<optimized out>) at /usr/include/c++/6/bits/shared_ptr_base.h:928
#4  0x00007f5b16d03928 in std::shared_ptr<opentracing::v2::Span>::~shared_ptr (this=0x55ac421e3b00, __in_chrg=<optimized out>)
    at /usr/include/c++/6/bits/shared_ptr.h:93
#5  0x00007f5b16d0641a in lua_bridge_tracer::LuaSpan::~LuaSpan (this=0x55ac421e3af0, __in_chrg=<optimized out>)
    at /cfsetup_build/lua-bridge-tracer/src/lua_span.h:10
#6  0x00007f5b16d08060 in lua_bridge_tracer::LuaSpan::free (L=0x41f64378) at /cfsetup_build/lua-bridge-tracer/src/lua_span.cpp:38
#7  0x00007f5b5975500a in lj_BC_FUNCC () from /usr/local/openresty/luajit/lib/libluajit-5.1.so.2
#8  0x00007f5b59757128 in gc_call_finalizer (g=g@entry=0x41f643b8, L=L@entry=0x41f64378, mo=<optimized out>, o=o@entry=0x41f779a8) at lj_gc.c:475
#9  0x00007f5b597571e6 in gc_finalize (L=L@entry=0x41f64378) at lj_gc.c:521
#10 0x00007f5b59758108 in lj_gc_finalize_udata (L=L@entry=0x41f64378) at lj_gc.c:528
#11 0x00007f5b5975e481 in cpfinalize (L=0x41f64378, dummy=<optimized out>, ud=<optimized out>) at lj_state.c:236
#12 0x00007f5b59755379 in lj_vm_cpcall () from /usr/local/openresty/luajit/lib/libluajit-5.1.so.2
#13 0x00007f5b5975e796 in lua_close (L=0x41f64378) at lj_state.c:262
#14 0x000055ac401560dc in ngx_http_lua_cleanup_vm (data=0x55ac422202b0) at ../ngx_lua-0.10.13/src/ngx_http_lua_util.c:3827
#15 0x000055ac400a2516 in ngx_destroy_pool (pool=0x55ac421d55d0) at src/core/ngx_palloc.c:60
#16 0x000055ac400c5e23 in ngx_worker_process_exit (cycle=cycle@entry=0x55ac421d5620) at src/os/unix/ngx_process_cycle.c:1071
#17 0x000055ac400c5fa7 in ngx_worker_process_cycle (cycle=cycle@entry=0x55ac421d5620, data=data@entry=0x0) at src/os/unix/ngx_process_cycle.c:814
#18 0x000055ac400c48ec in ngx_spawn_process (cycle=cycle@entry=0x55ac421d5620, proc=proc@entry=0x55ac400c5e80 <ngx_worker_process_cycle>,
    data=data@entry=0x0, name=name@entry=0x55ac401b8d3d "worker process", respawn=respawn@entry=-3) at src/os/unix/ngx_process.c:198
#19 0x000055ac400c63a0 in ngx_start_worker_processes (cycle=cycle@entry=0x55ac421d5620, n=1, type=type@entry=-3)
    at src/os/unix/ngx_process_cycle.c:396
#20 0x000055ac400c6d2a in ngx_master_process_cycle (cycle=0x55ac421d5620) at src/os/unix/ngx_process_cycle.c:135
#21 0x000055ac4009fcdd in main (argc=<optimized out>, argv=<optimized out>) at src/core/nginx.c:384
(gdb)

Could you check to see if this commit fixes the problem?

That commit doesn't fix the problem for me.

Here's the config I'm running OpenResty with - does anything stand out?
worker_processes        1;
error_log               /dev/stdout;
pid                     run/nginx.pid;

events {
    worker_connections  16;
    accept_mutex        off;
    multi_accept        off;
    use                 epoll;
}

http {
    opentracing on;
    opentracing_load_tracer /usr/local/lib/libjaegertracing_plugin.so jaeger-config.yml;

    opentracing_trust_incoming_span off;
    log_subrequest on;

    access_log          /dev/stdout;

    server {
        server_name 'proxy';
        listen 8004;

        location / {
            content_by_lua '
                local bridge_tracer = require("opentracing_bridge_tracer")
                local tracer = bridge_tracer.new_from_global()
                local parent_context = tracer:binary_extract(ngx.var.opentracing_binary_context)
                local span = tracer:start_span("lua-hello", {["references"] = {{"child_of", parent_context}}})
                ngx.say("
hello, world
")
                span:finish()
            ';
        }
    }
}

I think I found the issue. Could you check to see if this PR solves the problem?

That fixes it for me. Thanks!

authors: rnburn terrynsun

repo: opentracing/lua-bridge-tracer


text:
🛑 [CN] OpenUPM Website Packages is down

In c1c5668, [CN] OpenUPM Website Packages (https://openupm.cn/packages/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website Packages is back up in a40589b.

repo: openupm/upptime-openupmcn


text:
🛑 [CN] OpenUPM Website Docs is down

In 5552a38, [CN] OpenUPM Website Docs (https://openupm.cn/docs/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website Docs is back up in 822066e after 49 minutes.


text:
🛑 [CN] OpenUPM Website is down

In d5bf216, [CN] OpenUPM Website (https://openupm.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website is back up in fa82cb3.


text:
🛑 [CN] OpenUPM Registry /-/all is down

In 02fac23, [CN] OpenUPM Registry /-/all (https://package.openupm.cn/-/all) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Registry /-/all is back up in 989be87.

repo: openupm/upptime


text:
[Detection/Instance-Segmentation] Adaptive Training Schedule Hook

Summary
This PR includes :

Add Adaptive Training Hook for Updating validation interval with LR scheduler & Early-Stop scheduler
Apply Adaptive Training Hook (validation interval only) to Instance-segmentation & Object-detection
EMA fix (https://github.com/openvinotoolkit/model_preparation_algorithm/pull/39) merged in this PR
Apply Adaptive EMA Momentum

First of all, we were able to set it to the corresponding value and obtain training time in accordance with detection and instance-segmentation. However, we will experiment with additional experiments + adaptive interval in this regard.

Hi @eunwoosh, This is the code for applying adaptive validation interval. This is applied in a small dataset and increases up to 5 interval. Please check if there is anything that affects HPO.

@harimkang I checked that HPO works well with this PR.

LGTM.

authors: eunwoosh goodsong81 harimkang


text:
Chart - Time spent by the users

Implement Time spent by the users chart

https://github.com/openvitae-tech/blackboard-lms/pull/354

repo: openvitae-tech/blackboard-lms


text:
luci-app-firewall: MAC address list in Source MAC Address

This is not an issue but more like a suggestion. I am using v18.06.4 in my HomeHub 5A.
Under Traffic Rules in Network -> Firewall when you edit or create a new rule, there is a textbox for Source MAC Address line. It's perfect for single MAC address cases but to add multiple addresses you need to go custom and then copy paste the whole MAC addresses from DHCP page or somewhere else adding a space in betwen. Even if you add a list in config file yourself, only the first MAC address shows in the LuCI and rest are not displayed. (Later is a bug I think)
Although this could be rather simple if someone implements a list style just like there is for Wireless MAC Filter. Then this should be more simple to add/remove MAC addresses. Thank you.

Fixed in master

repo: openwrt/luci


text:
BUG: DHCP Leases "infinite" time shows as "expired" not as "unlimited" in IPv4

I'm on "LEDE Reboot SNAPSHOT r3025-c99f881 / LuCI Master (git-17.017.13638-9b7a5a4)", Router: Archer C7. And in this version of the latest LEDE, the DHCP IPv4 Leases which are set to "infinite" are showing as "expired". The IPv6 leases are fine, and showing as "unlimited", but the IPv4 ones show as "expired".
I see jow tried to fix this already, and the code in these two files below (also most of this is the same code, the admin_status should just call the lease_status, not copy the code into it).
luci/modules/luci-mod-admin-full/luasrc/view/admin_status/index.htm
luci/modules/luci-mod-admin-full/luasrc/view/admin_network/lease_status.htm
for( var i = 0; i < info.leases.length; i++ )
{
	var timestr;
	if (info.leases[i].expires === false)
		timestr = '<%:unlimited%>';
	else if (info.leases[i].expires <= 0)
		timestr = '<%:expired%>';
	else
		timestr = String.format('%t', info.leases[i].expires);

The commit was done here: https://github.com/openwrt/luci/commit/70bad4da4fcd44715445c36d8c4b9f8a00d92b4d
But at least on the latest LEDE, the infinite IPv4 leases.expires property is not getting set to false, and are showing up as expired. The "info.leases[i].expires" property has a value <-1470000000, and keeps going down as time runs.
Like I said the IPv6 does show as unlimited on my router, but the IPv4 infinite leases are not.

That is actually a consequence of using dnsmasq for DHCPv4; dnsmasq doesn't report infinite leases as -1, but as expiring the maximum time in the future it can set.  If you use odhcpd for DHCPv4 this will work as it should.  Not a LuCI bug.

Ah, thanks @cshoredaniel ! Good to know.
While in the latest LEDE snapshot r3025, it seems to use dnsmasq by default for IPv4? Or one of the apps set it? I just flashed the latest LEDE, then ran the commands below. I didn't explicitly change to dnsmasq.
opkg update
opkg install luci ipset tor ip-tiny
opkg install luci-theme-material luci-app-upnp luci-app-ddns luci-app-qos

If dnsmasq is the default for OpenWRT/LEDE, perhaps the unlimited lease check in LuCI should check the dnsmasq case? Perhaps a check if it's an insanely large negative number? or is there any other way?
if (info.leases[i].expires === false || info.leases[i].expires < -1470000000)

odhcpd is the default for ipv6 (I'm not sure if dnsmasq for ipv6 PR has been accepted yet) and dnsmasq is the default for ipv4.  To use odhcpd for ipv4 set 'option maindhcp 1' in the 'config odhcpd' section of '/etc/config/dhcp', or do 'uci set dnsmasq.@odhcpd[-1].maindhcp=1; uci commit dhcp'

@NvrBst I'm not sure exactly what dnsmasq reports; it may actually report the time as now - 1 or some such silliness.  I'd have to check /tmp/dhcp.leases and do date -d '@<epoch-from-tmp-dhcp.leases>'. the epoch is the large unsigned integer in /tmp/dhcp.leases and represents the number of seconds since the start of the unix epoch (a historical legacy date when it was first defined).

I see! Upon looking, dnsmasq stores infinite leases as "0" in the /tmp/dhcp.leases file. This corresponds to the 01/01/1970 00:00:00 GMT, in Unix EPOCH time. Since today's date is "1484889355". But the expires property is (EXPIRY DATE - TODAYS DATE). So it's 0-1484889355. So any value below -1484889355 works.
So if someone wanted to do a dnsmasq infinite check properly you could:

Check the /tmp/dhcp.leases file and see if it has a 0 as the time.

Since the DHCP Lease Table is pulling its information from:

XHR.poll(5, '<%=url('admin/network/dhcplease_status')%>'

Going to the URL: _http://192.168.0.1/cgi-bin/luci/admin/network/dhcplease_status_ shows that it only gives the expiry conversion, and not the original expiry date. So someone would have to alter the structs and put the expiry time, and original EXPIRY DATE. Then you can use that and check to see if it's 0 for an infinite lease --- More work.

The leases[i].expires property is just EXPIRY DATE - CURRENT DATE. So you could reverse this calculation and check to see if it's 0. Of course, playing with time can be smudgy with rounding.

Option 2 is probably the cleanest, Option 3 is the easiest. So if we were doing 3, we can just do the check in these two files as:
luci/modules/luci-mod-admin-full/luasrc/view/admin_status/index.htm
luci/modules/luci-mod-admin-full/luasrc/view/admin_network/lease_status.htm
					if (info.leases[i].expires === false || Math.trunc((new Date().getTime()/1000 + info.leases[i].expires)/10) == 0)
						timestr = '<%:unlimited%>';
					else if (info.leases[i].expires <= 0)
						timestr = '<%:expired%>';

Sent the following message to odhcpd maintainer and lede-dev mailing
list.
Hi Hans,
In LuCI GitHub issue 963 (https://github.com/openwrt/luci/issues/963),
a user discovered that LuCI incorrectly reports dnsmasq infinite
leasetime as expired because the LuCI check is based on odhcpd's -1 for
INFINITE_VALID, but dnsmasq uses 0 in the dhcp.leases file for
infinite leases.  Would it be preferable to sync odhcpd and dnsmasq
(I know odhcpd at one time used 0 for INFINITE_VALID in the statefile
but that that was changed, and I don't know why).  From a LuCI point of
view I'm not sure if there some caveat with the 0 value (I seem to
recall odhcpd uses 0 to represent something other than infinite, but I
could be wrong).  Before hacking on LuCI for the dnsmasq case I want to
make sure I understand what values are going to be found in the odhcpd
case.
User's findings (last comment only) reproduced below.
Regards,
Daniel
Begin forwarded message:
Date: Thu, 19 Jan 2017 22:38:34 -0800
From: NvrBst notifications@github.com
To: openwrt/luci luci@noreply.github.com
Mention
mention@noreply.github.com Subject: Re: [openwrt/luci] BUG: DHCP
Leases "infinite" time shows as "expired" not as "unlimited" in IPv4
(#963)
I see! Upon looking, dnsmasq stores infinite leases as "0" in the
/tmp/dhcp.leases file. This corresponds to the 01/01/1970 00:00:00
GMT, in Unix EPOCH time. Since today's date is "1484889355". But the
expires property is (EXPIRY DATE - TODAYS DATE). So it's 0-1484889355.
So any value below -1484889355 works.
So if someone wanted to do a dnsmasq infinite check properly you could:

Check the /tmp/dhcp.leases file and see if it has a 0 as the time.

Since the DHCP Lease Table is pulling its information from:

XHR.poll(5, '<%=url('admin/network/dhcplease_status')%>'

Going to the URL:
_http://192.168.0.1/cgi-bin/luci/admin/network/dhcplease_status_ shows
that it only gives the expiry conversion, and not the original expiry
date. So someone would have to alter the structs and put the expiry
time, and original EXPIRY DATE. Then you can use that and check to see
if it's 0 for an infinite lease --- More work. 5. The leases[i].expires
property is just EXPIRY DATE - CURRENT DATE. So you could reverse this
calculation and check to see if it's 0. Of course, playing with time
can be smudgy with rounding.

Option 2 is probably the cleanest, Option 3 is the easiest. So if we
were doing 3, we can just do the check in these two files as:
luci/modules/luci-mod-admin-full/luasrc/view/admin_status/index.htm
luci/modules/luci-mod-admin-full/luasrc/view/admin_network/lease_status.htm
					if (info.leases[i].expires ===
false || Math.trunc((new Date().getTime()/1000 +
info.leases[i].expires)/10) == 0) timestr = '<%:unlimited%>';
else if (info.leases[i].expires <= 0) timestr = '<%:expired%>';

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/openwrt/luci/issues/963#issuecomment-273989416

As you can tell it remains to be seen whether the fix is best done in core or here.

I see! Upon looking, dnsmasq stores infinite leases as "0" in the /tmp/dhcp.leases file. This corresponds to the 01/01/1970 00:00:00 GMT, in Unix EPOCH time. Today's date is "1484889355",  but the leases[i].expires property is (EXPIRY DATE - TODAYS DATE). So it's 0-1484889355. Thus any value below -1484889355'ish is infinite.
So if someone wanted to do a dnsmasq infinite check properly you have several options:

Check the /tmp/dhcp.leases file and see if it has a 0 as the time.
Since the DHCP Lease Table is pulling its information from:
XHR.poll(5, '<%=url('admin/network/dhcplease_status')%>'
Going to the URL: _http://192.168.0.1/cgi-bin/luci/admin/network/dhcplease_status_ shows that it only gives the expiry conversion, and not the original expiry date. So someone would have to alter the structs and put the expiry time, and original EXPIRY DATE into dhcplease_status . Then you can use that and check to see if it's 0 for an infinite lease --- more work.
The leases[i].expires property is just EXPIRY DATE - CURRENT DATE. So you could reverse this calculation and check to see if it's 0. Of course, playing with time can be smudgy with rounding.

Option 2 is probably the cleanest, Option 3 is the easiest. So if we were doing 3, we can just do the check in these two files as:
luci/modules/luci-mod-admin-full/luasrc/view/admin_status/index.htm
var ls = document.getElementById('lease_status_table');
if (ls)
{
	var localEpoch = new Date(info.localtime).getTime()/1000.0;
...
	for( var i = 0; i < info.leases.length; i++ )
	{
		var timestr;

		if (info.leases[i].expires === false || Math.trunc(localEpoch + info.leases[i].expires) == 0)
			timestr = '<%:unlimited%>';
		else if (info.leases[i].expires <= 0)
			timestr = '<%:expired%>';

luci/modules/luci-mod-admin-full/luasrc/view/admin_network/lease_status.htm
var tb = document.getElementById('lease_status_table');
if (st && st[0] && tb)
{
	var curEpoch = new Date().getTime()/1000.0;
...
	for( var i = 0; i < st[0].length; i++ )
	{
		var timestr;

		if (st[0][i].expires === false || Math.trunc((curEpoch + st[0][i].expires)/10) == 0)
			timestr = '<%:unlimited%>';
		else if (st[0][i].expires <= 0)
			timestr = '<%:expired%>';

For admin_status, we have "info.localtime" as a seed for the Date(info.localtime). When using this, it seems like adding info.leases[i].expires to it (and truncating) produces 0 all the time. It's very accurate.
For lease_status.htm, we do not have localtime variable to see, so we needed to use the currentTime. With testing, var curEpoch = new Date().getTime()/1000.0; was always about 1 to 2 seconds off of info.leases[i].expires. So I added a +/-10s check to that one. Maybe it's best to add the +/-10s check to both, I'm not too sure.
The first part of the check is the odhcpd version of the check. The second part checks the dnsmasq version. This just sees if the info.leases[i].expires is within +/-10s of 01/01/1970 00:00:00 GMT, which is 0 in EPOCH time. I did the +/- 10s, because the Date() function was not called at the same time as the leases.expires was calculated. In the admin_status page we had a seed and the +/-10s check may not be nessasary?
This works. I only did this check for the IPv4 part, since dnsmasq is only used by default with the IPv4. I left the IPv6 check as it was.
Of course if there is an easy way to get the Original Expiry Date from /tmp/dhcp.leases, or put the original date in the 'admin/network/dhcplease_status', then it would be best to use that and check if it's 0. Else the above works, and all you need to do is call one extra Date() call per table.

ah thanks daniel! I deleted my last comment and made a new one with just taking the "new Date()" call out of the for loop, cuz it didn't need to be in there.
But yea best to see if they can sync the odhcpd and dnsmasq cases. Thanks again for all your patience.

@NvrBst and I appreciate your taking the time to look further; there is only so much the regular devs can do in the time/resources we are able to contribute.

Shouldn't by default odhpcd be used for all DHCP? And leave the DNS to qnsmasq? Is there some special reason to keep using dnsmasq for DHCPv4?

@scineram That's the decision made by upstream; discussion of that belongs on http://lists.infradead.org/mailman/listinfo/lede-dev

and you also have to coordinate with https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Begin forwarded message:
@NvrBst Sadly this mya not be resolvable.
Date: Fri, 20 Jan 2017 08:59:23 +0100
From: Hans Dedecker dedeckeh@gmail.com
To: Daniel Dickinson lede-daniel@cshore.thecshore.com
Cc: LEDE Development List lede-dev@lists.infradead.org
Subject: Re: [LEDE-DEV] Fw: [openwrt/luci] BUG: DHCP Leases "infinite"
time shows as "expired" not as "unlimited" in IPv4 (#963)
Hi Daniel
odhcpd uses 0 to indicate a lease is expired while -1 is used to
reperesent infinite leasetime since the support of infinite leasetime
(http://lists.infradead.org/pipermail/lede-dev/2016-November/004133.html).
I have my doubts can you make a distinction in dnsmasq between
infinite leasetime and a lease which is expired knowing the code
quality of dnsmasq.
So I would prefer to keep -1 for infinite leasetime to make it clear
it's "infinite" and to make a distinction with an expired lease.
Hans
On Fri, Jan 20, 2017 at 7:58 AM, Daniel Dickinson
lede-daniel@cshore.thecshore.com wrote:

Hi Hans,
In LuCI GitHub issue 963 (https://github.com/openwrt/luci/issues/963),
a user discovered that LuCI incorrectly reports dnsmasq infinite
leasetime as expired because the LuCI check is based on odhcpd's -1
for INFINITE_VALID, but dnsmasq uses 0 in the dhcp.leases file for
infinite leases.  Would it be preferable to sync odhcpd and dnsmasq
(I know odhcpd at one time used 0 for INFINITE_VALID in the statefile
but that that was changed, and I don't know why).  From a LuCI point
of view I'm not sure if there some caveat with the 0 value (I seem to
recall odhcpd uses 0 to represent something other than infinite, but I
could be wrong).  Before hacking on LuCI for the dnsmasq case I want
to make sure I understand what values are going to be found in the
odhcpd case.
User's findings (last comment only) reproduced below.
Regards,
Daniel
Begin forwarded message:
Date: Thu, 19 Jan 2017 22:38:34 -0800
From: NvrBst notifications@github.com
To: openwrt/luci luci@noreply.github.com
Mention
mention@noreply.github.com Subject: Re: [openwrt/luci] BUG: DHCP
Leases "infinite" time shows as "expired" not as "unlimited" in IPv4
(#963)
I see! Upon looking, dnsmasq stores infinite leases as "0" in the
/tmp/dhcp.leases file. This corresponds to the 01/01/1970 00:00:00
GMT, in Unix EPOCH time. Since today's date is "1484889355". But the
expires property is (EXPIRY DATE - TODAYS DATE). So it's 0-1484889355.
So any value below -1484889355 works.
So if someone wanted to do a dnsmasq infinite check properly you
could:

Check the /tmp/dhcp.leases file and see if it has a 0 as the
time. 2. Since the DHCP Lease Table is pulling its information from:

XHR.poll(5, '<%=url('admin/network/dhcplease_status')%>'

Going to the URL:
_http://192.168.0.1/cgi-bin/luci/admin/network/dhcplease_status_ shows
that it only gives the expiry conversion, and not the original expiry
date. So someone would have to alter the structs and put the expiry
time, and original EXPIRY DATE. Then you can use that and check to see
if it's 0 for an infinite lease --- More work. 5. The
leases[i].expires property is just EXPIRY DATE - CURRENT DATE. So you
could reverse this calculation and check to see if it's 0. Of course,
playing with time can be smudgy with rounding.

Option 2 is probably the cleanest, Option 3 is the easiest. So if we
were doing 3, we can just do the check in these two files as:
luci/modules/luci-mod-admin-full/luasrc/view/admin_status/index.htm
luci/modules/luci-mod-admin-full/luasrc/view/admin_network/lease_status.htm
                                        if (info.leases[i].expires ===
false || Math.trunc((new Date().getTime()/1000 +
info.leases[i].expires)/10) == 0) timestr = '<%:unlimited%>';
else if (info.leases[i].expires <= 0) timestr =
'<%:expired%>'; ```

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/openwrt/luci/issues/963#issuecomment-273989416

Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Closing unless someone decides to work on dnsmasq and make this work.

Sometime in the future dhcpv4 will prob switch odhcp, and everything will work fine anyway.
Although, I don't think the way to fix this is to make dnsmasq mimic odhcp, but rather just have LuCI check odhcp and dnsmasq's conditions for an infinite lease. Which is just seeing if the lease expiry date is set to 01/01/1970 00:00:00 GMT (i.e. current time + the expiry time == 0).
var localEpoch = new Date(info.localtime).getTime()/1000.0;
...
if (info.leases[i].expires === false || Math.trunc(localEpoch + info.leases[i].expires) == 0)

It's only adding 2 lines of code to have LuCI check for dnsmasq infinite leases for the dhcpv4 case. If you use currentEpoch, you need to check within +/-10s.

@NvrBst Unfortunately from what Hans said, dnsmasq using 0 for expired strings as well as infinite strings; i.e. there is no differentiation based on his statement.

I have my doubts can you make a distinction in dnsmasq between infinite leasetime and a lease which is expired knowing the code quality of dnsmasq.

I think he is just saying that both cases are just expired leases in dnsmasq. So it may be difficult.
In fact, an infinite lease in dnsmasq is just a "lease with an expiry date of 01/01/1970 00:00:00 GMT". And an expired lease is just a "lease with an expiry date <= current date (and =! to above date)".
If the above is true, one can most definitely distinguish the different between infinite vs expired in dnsmasq by checking the expiry date.
So to test an expired lease you just test to see if the expiry date is <= current date. And if it's expired you see if the expiry date is = 01/01/1970 00:00:00 GMT, if so, it's not expired it's "infinite". If not, then it's just expired. NOTE: this test could also be done by looking at the /tmp/dhcp.leases file, and seeing if the EXPIRY DATE (first column = 0) which means EXPIRY DATE=01/01/1970 00:00:00 GMT. Problem is LuCI doesn't expose the EXPIRY DATE to us, just the REMAINING EXPIRY TIME. So you have to re-calculate the date.
That said, the 2 code changes above is distinguishing between infinite and expired leases in DHCPv4, as you can see in the below screenshots.
The top 2 leases are "infinite leases" and you can see this by the leases file = 0, below that. I set my lease time to 2m, and requested a lease on LAPTOP-NGG, then disconnected wifi. After the countdown occurred, the lease went to "expired". And the top 2 remained "unlimited". You can see in the dhcp.lease file, the unlimited leases has a DATE (first column) as 0, which is 01/01/1970 00:00:00 GMT, the expired lease has a date of 1485079535, and it remained that. which was a date that became lower than current EPOCH date. Note that shortly after this dnsmasq removed the expired lease from the leases file and thus LuCI remove the entry as well.

https://github.com/openwrt/luci/blob/70bad4da4fcd44715445c36d8c4b9f8a00d92b4d/modules/luci-base/luasrc/tools/status.lua#L32
Else you can change this file to alter the ".expires" property of the dnsmasq part. I can see jow changed this file to handle the odhcpd infinite case last month (infinite = -1, return false). You can change line 32 to just add a check if "ts" == 0, then return false (i.e. if expiry date = 1970 date then return "false=infinte") -- if it's not 0, then do what you do now, calcualte difference, if negative then expired, if not, then valid. The code change is below, mimics the odhcp case, just with a differnt check.
local expire = tonumber(ts) or 0
expires  = (expire ~= 0) and os.difftime(expire, os.time()),

I tested this on my system as well, and again it distinguishes between infinite and expire. And you do not have to change any of the checks in the HTML part. What's nice about this is that it makes the checks the same in the odhcp and dnsmasq case (.expires property is == false if infinite,  <= 0 if expired).
Screenshot of my system with the above change, and unaltered HTML status/dhcplease page.

The code change is below, mimics the odhcp case, just with a different check.

local expire = tonumber(ts) or 0
expires  = (expire ~= 0) and os.difftime(expire, os.time()),

That looks nice and elegant.

@NvrBst @hnyman Thanks for clarify; I clearly misread Hans comments.

I probably won't get to this for a while so I've unassignmed myself and marked it 'help wanted' in hopes someone else is willing and able to spin a patch.

Fixed with https://github.com/openwrt/luci/commit/0f35de886c98404f1bf75460f7a76b6cb463e1e1

authors: NvrBst cshoredaniel hnyman scineram


text:
https-dns-proxy support option use_http1

https-dns-proxy support option use_http1
Signed-off-by: Robin zhaoruibin@aliyun.com

Duplicate of #5553

authors: robinZhao stangri


text:
Version & DeviceID should be displayed correctly in json & protobuf

Version & DeviceID are displayed for json format. But not for protobuf. Needs some investigation

This is done and merged in next .

authors: kranjanford vkanishk

repo: openxc/openxc-ios-app-demo


text:
[feature request]please reserve UnitedDeployment resource for version compatibility.

What would you like to be added:
We should reserve UnitedDeployment resource in yurt-app-manager for one or two versions time, not rename it to YurtAppSet.
Why is this needed:
If end user is using UnitedDeployment, but UnitedDeployment disappeared suddenly, end users maybe fell confused and can not keep the compatibility for original workloads.
others
/kind feature

/assign @hxcGit

authors: hxcGit rambohe-ch

repo: openyurtio/yurt-app-manager


text:
Update to latest alpine image

Upgrading to address several CVEs that were picked up by a Trivy scan.

Close in favor of sticking with latest 3.15x https://github.com/openzipkin/docker-alpine/pull/21

repo: openzipkin/docker-alpine


text:
Browser is not closed when calling WebDriver#close()

When the method WebDriver#close() is called on the OperaWebDriver the browser is not closed, but only the current tab (the first time I see Opera without any tab).
This makes it impossible to test multiple Opera versions through one test suite.

The WebDriver interface says that WebDriver.close() should close the currently activated (focused) window.  If that is the last window, the browser instance should be quit.
I've addressed this now in 961324ef9b4c758e4ba94bcb435529bdf2d54bb9.
Thank you for reporting the bug (-:

authors: andreastt scrobbleme

repo: operasoftware/operadriver


text:
Add the Knative Serving Operator into the operatorhub

Thanks submitting your Operator. Please check below list before you create your Pull Request.

Flat operator directory structure is obsolete from 23-rd of October 2019, only nested directory structure will be accepted.

New Submissions

[ ] Has you operator nested directory structure?
[ ] Have you selected the Project Community Operator Submissions in your PR on the right-hand menu bar?
[ ] Are you familiar with our contribution guidelines?
[ ] Have you packaged and deployed your Operator for Operator Framework?
[ ] Have you tested your Operator with all Custom Resource Definitions?
[ ] Have you tested your Operator in all supported installation modes?
[ ] Is your submission signed?

Updates to existing Operators

[ ] Is your new CSV pointing to the previous version with the replaces property?
[ ] Is your new CSV referenced in the appropriate channel defined in the package.yaml ?
[ ] Have you tested an update to your Operator when deployed via OLM?
[ ] Is your submission signed?

Your submission should not

[ ] Modify more than one operator
[ ] Modify an Operator you don't own
[ ] Rename an operator - please remove and add with a different name instead
[ ] Submit operators to both upstream-community-operators and community-operators at once
[ ] Modify any files outside the above mentioned folders
[ ] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[ ] Description about the managed Application and where to find more information
[ ] Features and capabilities of your Operator and how to use it
[ ] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[ ] Human readable name and 1-liner description about your Operator
[ ] Valid category name1
[ ] One of the pre-defined capability levels2
[ ] Links to the maintainer, source code and documentation
[ ] Example templates for all Custom Resource Definitions intended to be used
[ ] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file a PR against this repo and explain your need
2 For more information see here

@dmesser Do I need to update the dir under community-operator first, and then update the dir under upstream-community-operator for knative-serving-operator?

@jcrossley3 I am not sure if you can help me with the metadata I am missing.

/recheck

/test CVP

Why is CVP test not launched?

/test CVP

/test CVP

/test CVP

/test CVP

/test CVP

/retest

@dmesser it's failing currently since the metadata is having issues, also this PR tries to ship ConfigMap yamls, which has been fixed upstream

@houshengbo @matzew closing for now until you update this PR with the fixes from upstream :)

authors: dmesser houshengbo matzew

repo: operator-framework/community-operators


text:
Operators should be reconciled on any CatalogSources change

Background:
When reconciling operator CRs, the operator-controller builds a list of constraints based on operator CRs and attempts to solve those constraints by considering content available in catalogSources. If the content within a catalogSource changes, a new solution may be available for a set of constraints that had failed earlier.
The operator controller should be updated to watch catalogSources. On changes that affect the catalogContent, the operator controller should queue all operator CRs to be reconciled. For the purposes of this ticket, we will queue all operator CRs for any catalog event, even if content might not have changed.
Demo Script:
install OLM V1
Remove the default catalogSource
Create an Operator CR that exists in the catalog
Check that it fails
Recreate the default catalogSource
Check that the package defined in the operator CR is deployed

Demoed in the June 13th, 2023 Working Group and Issue Triage Meeting, viewable here.

repo: operator-framework/operator-controller


text:
Bug 1867169: Fix stale content in configmap due to stale bundle image in the node

If the bundle is already present in the node, during the unpack process
the configmap may potentially use a stale bundle image. The default
setting for ImagePullPolicy is IfNotPresent and should be changed to
Always.
Signed-off-by: Vu Dinh vdinh@redhat.com

Description of the change:
Motivation for the change:
Reviewer Checklist

[ ] Implementation matches the proposed design, or proposal is updated to match implementation
[ ] Sufficient unit test coverage
[ ] Sufficient end-to-end test coverage
[ ] Docs updated or added to /docs
[ ] Commit messages sensible and descriptive

This does potentially cause more egress from the cluster but the fix is necessary for the update feature to work correctly.
Also I assume this will also work in disconnected environments (since all bundle images are hosted internally) and shouldn't break anything else.
/lgtm

/retest

/retest

/retest

/approve

/retest

/retest

/retest

/retest

/retest

/retest

/cherry-pick release-4.5

authors: dinhxuanvu ecordell exdx


text:
scripts: add --go-ldflags argument to operator-sdk build command

Description of the change:
Add --go-ldflags support to operator-sdk build command
Motivation for the change:
I need to provide build time arguments to my operator such as version. With this MR I am able to run:
operator-sdk build image-name --go-ldflags "-X package.Version=vX.Y.Z"

Fixes #1435

Sure, I'll have a look at it.

I generalized it & amended my commit, now we can provide any additional arguments. Now it works like:
operator-sdk build image-name --go-build-args "-ldflags -X=package.Version=vX.Y.Z"

@ZoltanOnody thanks so much!
/ok-to-test

You can ignore the marker test, it seems to be behaving oddly right now. But the e2e test seems to be failing as well.

/retest

The test seems to be working locally:
+ kubectl create namespace test-memcached
namespace/test-memcached created
+ operator-sdk test local ./test/e2e --up-local --namespace=test-memcached
INFO[0000] Testing operator locally.
ok  	github.com/operator-framework/operator-sdk/test/test-framework/test/e2e	47.360s
INFO[0049] Local operator test successfully completed.

In Travis I see:
+operator-sdk test local ./test/e2e --up-local --namespace=test-memcached
INFO[0000] Testing operator locally.
time="2019-06-21T17:22:13Z" level=info msg="Started local operator"
--- FAIL: TestMemcached (80.15s)
    --- FAIL: TestMemcached/memcached-group (0.00s)
        --- FAIL: TestMemcached/memcached-group/Cluster2 (60.02s)
            memcached_test.go:100: Initialized cluster resources
            wait_util.go:48: Operator is running locally; skip waitForDeployment
            client.go:57: resource type  with namespace/name (test-memcached/example-memcached) created
            wait_util.go:64: Waiting for full availability of example-memcached deployment (0/3)
            wait_util.go:64: Waiting for full availability of example-memcached deployment (0/3)
            wait_util.go:64: Waiting for full availability of example-memcached deployment (0/3)
            wait_util.go:64: Waiting for full availability of example-memcached deployment (0/3)
            wait_util.go:64: Waiting for full availability of example-memcached deployment (0/3)
            wait_util.go:64: Waiting for full availability of example-memcached deployment (0/3)
            wait_util.go:64: Waiting for full availability of example-memcached deployment (0/3)
            wait_util.go:64: Waiting for full availability of example-memcached deployment (0/3)
            wait_util.go:64: Waiting for full availability of example-memcached deployment (0/3)
            wait_util.go:64: Waiting for full availability of example-memcached deployment (0/3)
            wait_util.go:64: Waiting for full availability of example-memcached deployment (0/3)
            wait_util.go:64: Waiting for full availability of example-memcached deployment (0/3)
            wait_util.go:64: Waiting for full availability of example-memcached deployment (0/3)
            memcached_test.go:114: timed out waiting for the condition
            client.go:75: resource type  with namespace/name (test-memcached/example-memcached) successfully deleted
FAIL

I think is just some random error caused by network issues in Travis. Could you please restart the job https://travis-ci.org/operator-framework/operator-sdk/jobs/548782267?

@ZoltanOnody retriggered that test.
Can you also rebase to current master, the marker test should be fixed by doing that, thanks for your patience!

I rebased my branched and forcepushed it. When you retriggered the job, it passed so the failing test was not caused by my changes. :)

Is it OK to change it using "Commit suggestion" via Github (I've seen this feature for the first time), or should a squash my commits locally and force push?
BTW, do you have any ETA for the next release of operator-sdk?

Is it OK to change it using "Commit suggestion" via Github (I've seen this feature for the first time), or should a squash my commits locally and force push?

Yep. Using "commit suggestion" is totally fine. When one of the maintainers actually does the merge, GitHub automatically squahes everything for us, so you don't have to squash and force push.

BTW, do you have any ETA for the next release of operator-sdk?

Probably later this week unless something comes up that forces us to push it back.

authors: LiliC ZoltanOnody joelanford shawn-hurley

repo: operator-framework/operator-sdk


text:
doc: add backport policy

Description of the change:

add backport policy

Motivation for the change:
Discussion in Eng, Forum

/lgtm

/lgtm


text:
Fd sparse

Finite-difference for sparse functions.
It does not produces FD expression as for Function as spatial indices are not present in the SparseFunction but instead a list of expression with offsets for each dimension to be processed at injection.
Missing:

Proper tests (in progress)
Some more shortcuts (laplace, div, ....). Some are missing for Function so I'll add it to

Some dtype fix in the tests.

I think I addressed all comments. Travis still fails on timeout for some reasons (never same one).

Codecov Report

Merging #493 into master will decrease coverage by 0.37%.
The diff coverage is 67.3%.

@@            Coverage Diff             @@
##           master     #493      +/-   ##
==========================================
- Coverage   86.48%   86.11%   -0.38%
==========================================
  Files          73       73
  Lines        6297     6372      +75
  Branches     1286     1318      +32
==========================================
+ Hits         5446     5487      +41
- Misses        674      702      +28
- Partials      177      183       +6

Impacted Files
Coverage Δ

devito/finite_difference.py
65.81% <51.61%> (-5.46%)
:arrow_down:

devito/function.py
88.94% <73.97%> (-3.7%)
:arrow_down:

Continue to review full report at Codecov.

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

#515 should help for this. Closing for now to cleanup PR list, will reopen later.

authors: codecov-io mloubout

repo: opesci/devito

license: mit


text:
Compiling Firmware

Hello,
Thank you very much for the project, and all the detailed information,
i have a little issue with compiling the firmware, after 5 hours of testing and research i was unable to compile the firmware using the Make file, i think i installed everything like it should but i am getting 1 error , the compilation is creating a build folder , with an empty version file.
I am not a code expert , i really tried , but i seem to be missing something. i can really use some help or the files already compiled , it will be great .(unless a step by step explanation is possible , it would be interesting to see what i am doing wrong ).
Thank you very much,
i am using windows 10
i tested:
-GNU arm gnu 14.2
-winget install ezwinports.make in win cmd

cygwin with the correspondant packages for make .....

I have published pre-built firmware binaries here, so would you like to try this?
Actually, I developed this gadget entirely on a Mac, and the Makefile for building the firmware was designed with Unix-like environments in mind. Because of this, building it on a Mac or Linux should work without any issues. However, attempting to build it in a native Windows environment might be challenging just to gather the necessary tools.
I’m not familiar with the numerous Posix-compatible environments available for Windows, so I can’t provide precise advice on how to proceed. That said, these days, using WSL2 is probably the easiest way to get things working without much hassle. Earlier, I tried building the firmware for simhid-g1000 on WSL2 (Ubuntu) with nothing more than the Arm GNU Toolchain installed, and everything worked perfectly without any issues.
In any case, not including this kind of information in the README might have made things a bit unclear. I’ll update the README to address this. Thank you for your report.

Thank you for your fast response & sharing the files,
i really appreciated , i will be testing everything this evening, and retrying with wsl2 & will try flashing with the files you shared too.
Anyways i will Keep you posted & great job man,
best regards

authors: mAkhenaton opiopan


text:
Add TSC Charter

Signed-off-by: Kyle Mestery mestery@mestery.com

This is the one that was signed by all members using the LF portal back in June correct? Does the one Sridhar posted in Slack need to be voted on during the first TSC meeting, or was that done via email already?

This new one was already approved by the TSC in a private vote.

repo: opiproject/opi


text:
if validation of CSRF token fails, a empty 200 page is returned

if OPNsense\Base\ApiControllerBase\beforeExecuteRoute is failing due to the CSRF token https://goo.gl/bxTNBX the result is an 200 WSOD - i dont think that is supposed to happen, at least a 403?

Yes, we should return a 403

authors: AdSchellevis EugenMayer

repo: opnsense/core


text:
security/acme-client: Add RegRu API dns challenge type

Add RegRu API dns challenge type
https://github.com/acmesh-official/acme.sh/blob/master/dnsapi/dns_regru.sh

Merged, thanks!

authors: dmitry-sk fraenki

repo: opnsense/plugins


text:
dns/bind: lost ports, templating, update to dnsbl.ch

ports in form/model got lost with last PR
split dnsbl.sh to select every list
added blacklist.sh
added action for cronjob

before releasing I have to rework blacklist stuff .. it seems loading every blacklisted domain as an own zone has a way too big memory footprint. RPZ seems to be better ...

regarding the memory issue I'll have to check again, it seems my dev machine was affected by suricata issue and ran out of mem, not related to BIND

Merged, thanks!

authors: fichtner mimugmail


text:
[issue_32] fix conversion to dict

This PR fixes the conversion from OpossumPackage to dict. As I used the asdict method before, the to_dict() method of the Resource objects wasn't called and the generated output included additional children tags. I didn't notice this as we didn't have a test to check the actual output. So, I added a test to check the generated opossum file and fixed the issue. I decided to write a custom to_dict method as the asdict method from dataclasses doesn't allow different dict_factories for nested dataclasses. The type hints for this method are rather general to avoid complains from mypy.
#fixes 32

Thanks for answering the comments. You can merge if you want!

authors: JakobSchubert meretp


text:
host_header changes not applying on config

Oops sorry, I did this backwards because admittedly I didn't read the contribution guidelines until after creating the pull request.
I noticed host_header changes would only take effect on add, not on config.
This seems to be because is_new_port_host_provided is checking to see if the binding combo is already included, which it never will be. This prevents the binding being added on line 79. This commit just flips the logic.
It also fixes an edge-case where a config change with a host-header of localhost-foo -> localhost wouldn't get applied (since technically http/*:80:localhost is included in http/*:80:localhost-foo).

Resolved #134  and merged

repo: opscode-cookbooks/iis


text:
conform to new chefspec matcher definition syntax for versions of chefspec >= 4.1

chefspec 4.1.0 and greater displays deprication messages when using the ChefSpec::Runner.define_runner_method syntax. This updates these to use the new define_matcher but should not break those using the older chefspec gem.

This fix is included in versions 1.36.1, which was released to supermarket.

authors: kowal mwrock

repo: opscode-cookbooks/windows


text:
Add the fallback path for String(input) failure in assertIsErrorInstance()

This relaxes the problem of that String(input) fails by input has .toString() but it fails.
Essentially, this is not our business. It would be  But we need to do this to avoid changes both of behavior and host environment requirement.

I retake this problem by #1834

repo: option-t/option-t


text:
chats list for the current user

Add endpoint GET /chats. It must return all chats for the current user (where she/he is a participant). List should be sorted against last message posted in chat.
Backend should return array of objects:

id - chat-id
topic
kind (application, contract)
title (job title or contract title depends on kind)
job_id, if applicable
application_id, if applicable
contract_id, if applicable
paricipants[]

id

display_name

ethereum_address

👍

repo: optriment/optrispace-backend


text:
Add ui to archive/unarchive companies

before -

after -

Please remove text from these buttons
Place buttons after Payments button
Set the correct buttons size
Remove the background color
Replace the images with another


text:
chore(main): release 0.16.1

:robot: I have created a release beep boop
0.16.1 (2024-08-21)
Bug Fixes

add delete block in cluster config (bd09078)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v0.16.1
:sunflower:


text:
Which components of the Hyperion Stack are using Windows?

Hi, I notice that there is a comment that Windows 2016 is used when building the Hyperion stack. Is this all components or just a subset. Would be grateful for advice.

All the compute instances in the app tier afaik.  [@rishimahajan - pls confirm]
The bastion is a Linux instance though.

All compute instances are Windows 2016. The database is PAAS service on Oracle Linux

authors: kumar-dhanagopal nmcaully rishimahajan

repo: oracle-quickstart/oci-hyperion


text:
add flexibility and conditionals regarding variables

added more documentation and conditionals to adduser playbook

OK with me.

authors: bgraef simonhayler

repo: oracle-samples/ansible-collections


text:
centos2ol.sh: line 7: syntax error near unexpected token `newline'

I have done a fresh install of CentOS 8 in Contabo VPS I download the centos2ol.sh script to try to convert it to Oracle Linux but I get the following errors

centos2ol.sh: line 7: syntax error near unexpected token `newline'

centos2ol.sh: line 7: `'

How are you downloading the script? This feels like a character encoding issue which can happen if you download using Windows, for example.

How are you downloading the script? This feels like a character encoding issue which can happen if you download using Windows, for example.

I don't remember the last time I used a Windows machine, maybe 16 or 18 years I download the script using wget

If it's not character encoding, maybe the wrong shell interpreter. Are you sure you're  running it with bash?

IIRC loading a script using the sh command will make Bash operate in POSIX-sh compatibility mode, which may cause problems, just my 2 cents...

If it's not character encoding, maybe the wrong shell interpreter. Are you sure you're running it with bash?

Yes I'm running it with bash but it gives the same error it does no matter if you try to run it using bash, sh or ./

Except I can't reproduce this no matter whether I use bash, sh or ./ -- it works with all three. Can you provide the content of /etc/os-release and uname -a? We're obviously missing something, now we just have to work out what.

Except I can't reproduce this no matter whether I use bash, sh or ./ -- it works with all three. Can you provide the content of /etc/os-release and uname -a? We're obviously missing something, now we just have to work out what.

Solved

Solved

Would you mind telling us how, just in case this comes up again?

I had the same issue.  What it was for me was that I right-clicked on the hyperlink in the "Either clone this repository or download the centos2ol.sh script." line and then did a wget for that hyperlink.  Rather than this downloading the script, it downloaded the web page for acquiring the script, thus the errors:
./centos2ol.sh: line 7: syntax error near unexpected token `newline'
./centos2ol.sh: line 7: `<!DOCTYPE html>'

I deleted the file, and then actually downloaded the script directly. :)
I thought I'd share since this is the only hit for the error, and it was annoying to be simply "solved" without explanation.

I had the same issue.  What it was for me was that I right-clicked on the hyperlink in the "Either clone this repository or download the centos2ol.sh script." line and then did a wget for that hyperlink.  Rather than this downloading the script, it downloaded the web page for acquiring the script, thus the errors:
./centos2ol.sh: line 7: syntax error near unexpected token `newline'
./centos2ol.sh: line 7: `<!DOCTYPE html>'

I deleted the file, and then actually downloaded the script directly. :)
I thought I'd share since this is the only hit for the error, and it was annoying to be simply "solved" without explanation.

Oh, that makes sense! I've submitted a PR to fix that.

Oh, that makes sense! I've submitted a PR to fix that.

Now to figure out why I'm getting a dracut timeout after conversion. ;)

Now to figure out why I'm getting a dracut timeout after conversion. ;)

Looks good now Avi!  Thanks.  I also edited my initial posting's hyperlink, just so the old link isn't hanging around there too. :)

Looks good now Avi!  Thanks.  I also edited my initial posting's hyperlink, just so the old link isn't hanging around there too. :)

authors: Djelibeybi Lin-Buo-Ren anark1a fregiventum